Sách hay: Khám phá sâu kiến trúc quan hệ dữ liệu–lý thuyết & thực hành Access 2010


Microsoft Access 2010 has a collection of wizards to lead you step-by-step through each process involved in developing and using a production-grade database application. ‘ Exploring Relational Database Theory and Practice ‘ is extracted from ‘ Microsoft Access 2010 In Depth’, published by Que.

Moving from Spreadsheets to Databases

Word processing and spreadsheet applications were the engines that drove the fledgling personal computer market. In the early PC days, WordPerfect and Lotus 1-2-3 dominated the productivity software business. Today, most office workers use Microsoft Word and Excel on a daily basis. It’s probably a safe bet that more data is stored in Excel spreadsheets than in all the world’s databases. It’s an equally good wager that most new Access users have at least intermediate-level spreadsheet skills, and many qualify as Excel power users.

Excel 2010’s Data ribbon offers elementary database features, such as sorting, filtering, validation, and data entry forms. You can quickly import and export data in a variety of formats, including those of database management applications, such as Access. Excel’s limitations become apparent as your needs for entering, manipulating, and reporting data grow beyond the spreadsheet’s basic row-column metaphor. Basically, spreadsheets are list managers; it’s easy to generate a simple name and address list with Excel. If your needs expand to contact management and integrating the contact data with other information generated by your organization, a spreadsheet isn’t the optimal approach.

Related Articles

  • Getting Up To Speed With Microsoft Access 2010
  • Book Review: The Excel Analyst’s Guide to Access
  • What’s new in Access 2010

The first problem arises when your contacts list needs additional rows for multiple persons from a single company. You must copy or retype all the company information, which generates redundant data. If the company moves, you must search and replace every entry for your contacts at the firm with the new address. If you want to record a history of dealings with a particular individual, you add pairs of date and text columns for each important contact with the person. Eventually, you find yourself spending more time navigating the spreadsheet’s rows and columns than using the data they contain.

Contact lists are only one example of problems that arise when attempting to make spreadsheets do the work of databases. Tracking medical or biological research data, managing consulting time and billings, organizing concert tours, booking artist engagements, and myriad other complex processes are far better suited to database than spreadsheet applications.

Moving to a relational database management system (RDBMS), such as Access, solves data redundancy and navigation problems and greatly simplifies updating existing information. After you understand the basic rules of relational database design, Access makes creating highly efficient databases quick and easy. Access 2010 has a collection of wizards to lead you step-by-step through each process involved in developing and using a production-grade database application. Unfortunately, no “Relational Wizard” exists to design the underlying database structure for you, but you’ll find a wealth of pre-built database templates in the Backstage page’s New tab. (Click the ribbon’s File tab to open the new Backstage page.)


If your goal is learning relational database fundamentals, start with Access 2010. Access is by far the first choice of universities, colleges, trade schools, and computer-training firms for courses ranging from introductory data management to advanced client/server database programming. The reason for Access’s popularity as a training platform is its unique combination of initial ease of use and support for advanced database application development techniques

Reliving Database History

Databases form the foundation of world commerce and knowledge distribution. Without databases, there would be no World Wide Web, automatic teller machines, credit/debit cards, or online airline reservation systems. Newsgathering organizations, research institutions, universities, and libraries would be unable to categorize and selectively disseminate their vast store of current and historical information. It’s difficult to imagine today a world without a network of enormous databases, many of which probably contain a substantial amount of your personal data that you don’t want to be easily available to others.


Jim Gray’s article, “Data Management: Past, Present, and Future,” which is available as a Microsoft Word document at http://research.microsoft.com/~gray/DB_History.doc, offers a more detailed history of data processing systems. Dr. Gray was a senior researcher and the manager of Microsoft’s Bay Area Research Center (BARC) until early 2007, when he became lost at sea while sailing off the California coast

The Early History of Databases

The forerunner of today’s databases consisted of stacks of machine-readable punched cards, which Herman Hollerith used to record the 1890 U.S. census. Hollerith formed the Computing-Tabulating-Recording Company, which later became International Business Machines. From 1900 to the mid-1950s, punched cards were the primary form of business data storage and retrieval, and IBM was the primary supplier of equipment to combine and sort (collate) punched cards, and print reports based on punched-card data.

The development of large computer-maintained databases—originally called databanks—is a post–World War II phenomenon. Mainframes replaced punched cards with high-capacity magnetic tape drives to store large amounts of data. The first databases were built on the hierarchical and network models, which were well suited to the mainframe computers of the 1950s. Hierarchical databases use parent-child relationships to define data structures, whose diagrams resemble business organization charts or an inverted tree with its root at the top of the hierarchy. Network databases allow relaxation of the rules of hierarchical data structures by defining additional relationships between data items. Hierarchical and network databases ordinarily are self-contained and aren’t easy to link with other external databases over a network.

Early databases used batch processing for data entry and retrieval. Keypunch operators typed data from documents, such as incoming orders. At night, other operators collated the day’s batch of punched cards, updated the information stored on magnetic tape, and produced reports. Many smaller merchants continue to use batch processing of customer’s credit-card purchases, despite the availability of terminals that permit almost instantaneous processing of credit- and debit-card transactions.


Hierarchical databases remain alive and well in the twenty-first century. For example, data storage for Windows 2000’s Active Directory and Microsoft Exchange Server is derived from the hierarchical version of Access’s original relational Jet databases. The name Jet comes from the original Access database engine called Joint Engine Technology.

The Internet’s Domain Name System (DNS) is a collection of hierarchical databases for translating character-based Internet domain names into numerical Internet Protocol (IP) addresses. The DNS database is called a distributed database, because its data is held by a global network of thousands of computers.

The Relational Database Model

Dr. E. F. Codd, an employee of IBM Corporation, published “A Relational Model of Data for Large Shared Databanks” in a journal of the Association for Computing Machinery (ACM) in June 1970. A partial copy of the paper is available at http://www.acm.org/classics/nov95/. Dr. Codd’s specialty was a branch of mathematics called set theory, which includes the concept of relations. He defined a relation as a named set of tuples (records or rows) that have attributes (fields or columns). One of the attributes must contain a unique value to identify each tuple. The common term for relation is a table whose presentation to the user is similar to that of a spreadsheet.

Relational databases solve a serious problem associated with earlier database types. Hierarchical and network databases define sets of data and explicit links between each data set as parent-child and owner-member, respectively. To extract information from these databases, programmers had to know the structure of the entire database. Complex programs in COBOL or other mainframe computer languages are needed to navigate through the hierarchy or network and extract information into a format understandable by users.

Dr. Codd’s objective was to simplify the process of extracting formatted information and make adding or altering data easier by eliminating complex navigational programming. During the 1970s, Dr. Codd and others developed a comparatively simple language, Structured Query Language (SQL), for creating, manipulating, and retrieving relational data. With a few hours of training, ordinary database users could write SQL statements to define simple information needs and bypass the delays inherent in the database programming process. SQL, which was first standardized in 1985, now is the lingua franca of database programming, and all commercial database products support SQL.

Client/Server and Desktop RDBMSs

In the early database era, the most common presentation of data took the form of lengthy reports processed by centralized, high-speed impact printers on fan-folded paper. The next step was to present data to the user on green-screen video terminals, often having small printers attached, which were connected to mainframe databases. As use of personal computers gained momentum, terminal emulator cards enabled PCs to substitute for mainframe terminals. Mainframe-scale relational databases, such as IBM’s DB2, began to supplement and later replace hierarchical and network databases, but terminals continued to be the primary means of data entry and retrieval.


The most widely used SQL standard, SQL-92, was published by the American National Standards Institute (ANSI) in 1992. Few, if any, commercial relational database management systems (RDBMSs) today fully conform to the entire SQL-92 standard. The later SQL-99 (also called SQL3) and SQL-200n specifications add new features that aren’t germane to Access databases.

RDBMS competitors have erected an SQL Tower of Babel by adding nonstandard extensions to the language. For example, Microsoft’s Transact-SQL (T-SQL) for SQL Server, which is the subject of Chapter 27, “Moving from Access Queries to Transact-SQL,” has many proprietary keywords and features. Oracle Corporation’s Oracle:SQL and PL/SQL dialects also have proprietary SQL extensions.

Oracle, Ingres, Informix, Sybase, and other software firms developed relational databases for lower-cost minicomputers, most of which ran various flavors of the UNIX operating system. Terminals continued to be the primary data entry and display systems for multiuser UNIX databases.

The next step was the advent of early PC-based flat-file managers and relational database management systems. Early flat-file database managers, typified by Jim Button’s PCFile for DOS (1981) and Claris FileMaker for Macintosh (1988) and Windows (1992), used a single table to store data and offered few advantages over storing data in a spreadsheet. The early desktop RDBMSs—such as dBASE, Clipper, FoxBase, and Paradox—ran under DOS and didn’t support SQL. These products later became available in multiuser versions, adopted SQL features, and eventually migrated to Windows. Access 1.0, which Microsoft introduced in November 1992, rapidly eclipsed its DOS and Windows competitors by virtue of Access’s combination of graphical SQL support, versatility, and overall ease of use.

PC-based desktop RDBMSs are classified as shared-file systems because they store their data in conventional files that multiple users can share on a network. One of Access’s initial attractions for users and developers was its capability to store all application objects—forms, reports, and programming code—and tables for a database application in a single file, which used the earlier .mdb extension.. FoxPro, dBASE, Clipper, and Paradox require a multitude of individual files to store application and data objects. Today, almost every multiuser Access application is divided (split) into a front-end .accdb file, which contains application objects and links to a back-end database .accdb file that holds the data. Each user has a copy of the front-end .accdb file and shares connections to a single back-end .accdb file on a peer Windows workstation or server.


Prior to Access 2000, Jet was Access’s standard database engine, so the terms Access database and Jet database were interchangeable. Microsoft considered SQL Server to be its strategic RDBMS for Access 2000 and 2003. Strategic means that SQL Server gets continuing development funds and Jet doesn’t. Jet 4.0, which was included with Access 2003 and is a part of the Windows XP and later operating systems, is the final version and is headed toward retirement.

Microsoft’s Access team decided to enhance Jet 4.0 with the new features described in Chapter 1, “Access 2010 for Access 2007 Users: What’s New,” change the file extension from .mdb to .accdb, and drop all references to Jet. To reflect this change, this edition uses the terms Access database and SQL Server database. Unless otherwise noted, SQL Server refers to all SQL Server 2005 editions except the Compact and Mobile editions.

Client/server RDBMSs have an architecture similar to Access’s front-end/back-end shared-file multiuser configuration. What differentiates client/server from shared-file architecture is that the RDBMS on the server handles most of the data-processing activity. The client front end provides a graphical user interface (GUI) for data entry, display, and reporting. Only SQL statements and the specific data requested by the user pass over the network. Client/server databases traditionally run on network operating systems, such as Windows and UNIX, and are much more robust than shared-file databases, especially for applications in which many users make simultaneous additions, changes, and deletions to the database. All commercial data-driven Web applications use client/server databases.


This book uses the terms field and record when referring to tables, and columns and rows when discussing data derived from tables, such as the views and query result sets described later in this chapter.

Since version 1.0, Access has had the capability to connect to client/server databases by linking their tables to an Access database. Linking lets you treat client/server tables almost as if they were native Access tables. Linking uses Microsoft’s widely accepted Open Database Connectivity (ODBC) standard, and Access 2010 includes an ODBC driver for SQL Server and Oracle databases. You can purchase licenses for ODBC drivers that support other UNIX or Windows RDBMSs, such as Sybase or Informix, from the database supplier or third parties. Chapter 19, “Linking Access Front Ends to Access and Client/Server Databases,” describes the process of linking Access and Microsoft SQL Server 2008 databases. Although Chapter 19 uses SQL Server for its examples, the linking procedure is the same for—or at least similar to—other client/server RDBMSs.

Access data projects (ADP) and the Microsoft SQL Server 2005 Express Edition combine to make Access 2010 a versatile tool for designing and testing client/server databases and creating advanced data entry and reporting applications. You can start with a conventional Access database and later use Access’s Upsizing Wizard to convert the .mdb file(s) to an .adp file that holds application objects and an SQL Server 2005 back-end database. Access 2010’s Upsizing Wizard has incorporated many improvements to the Access 2000 and earlier wizard versions, but Access 2010’s Wizard is the same as 2007’s. Despite the upgraded wizardry, you’re likely to need to make changes to queries to accommodate differences between Access and SQL Server’s SQL dialects.

  • For an example of differences between Access and SQL Server SQL syntax that affects the upsizing process, see “Displaying Data with Queries and Views,” p. XXX (this chapter).

Defining the Structure of Relational Databases

Relational databases consist of a collection of self-contained, related tables. Tables typically represent classes of physical objects, such as customers, sales orders, invoices, checks, products for sale, or employees. Each member object, such as an invoice, has its own record in the invoices table. For invoices, the field that uniquely identifies a record, called a primary key[field], is a serial invoice number.

Figure 4.1 shows Access’s Datasheet view of an Invoices table, which is based on the Northwind.mdb sample database’s Orders table. The InvoiceNo field is the primary key. Values in the OrderID, CustomerID, EmployeeID, and ShipperID fields relate to primary key values in Northwind’s Orders, Customers, Employees, and Shippers tables. A field that contains values equal to those of primary key values in other tables is called a foreign key [field].

Figure 4.1

This simple Invoices table was created from the Northwind Orders table and doesn’t take advantage of Access’s extended properties, such as the field captions, lookup fields, and subdatasheets in the Datasheet view of the Orders table.

  • To learn more about primary keys in Access tables, see “Selecting a Primary Key,” p. XXX (Chapter 5).

If you need information about a particular invoice or set of invoices, open the Invoices table and search for the invoice(s) by number (InvoiceNo) or another attribute, such as a customer code (CustomerID), date (ShippedDate), or range of dates. Unlike earlier database models, the user can access the Invoices table independently of its related tables. No database navigation programming is needed. A simple, intuitive SQL statement, SELECT * FROM Invoices, returns all the data in the table. The asterisk (*) represents a request to display the contents of all fields of the table.

Removing Data Redundancy with Relationships

The Invoices table of Figure 4.1 is similar to a spreadsheet containing customer billing information. What’s missing is the customer name and address information. A five-character customer code (CustomerID) identifies each customer to whom the invoice is directed. The CustomerID values in the Invoices table match CustomerID values in a modified version of Northwind’s Customers table (see Figure 4.2). Matching a foreign key with a primary key value often is called a lookup operation. Using a key-based lookup operation eliminates the need to repeatedly enter name, address, and other customer-specific data in the Invoices table. In addition, if you change the customer’s address, the change applies to all past and future invoices.


Figure 4.2

Foreign key values in the Invoices table must match primary key values in the Customers table.

The Invoices table also connects with other tables, which contain information on orders, sales department employees, and the products ordered. Connections between fields of related tables having common values are called relationships (not relations). Figure 4.3 shows Access’s Relationships window displaying the relationships between the Invoices table and the other tables of the Northwind sample database.

Figure 4.3

Access’s Relationships window displays the relationships between the tables of the Northwind sample database, plus the added Invoices table. Every relationship between these tables is one-to-many. The many-to-many relationship between Products and Orders is an indirect relationship.


Using derived key values, such as alphabetic codes for Customer, is no longer in favor among database designers. Most designers now use automatically generated numerical key values—called Access AutoNumber or SQL Server identity fields. The Northwind Orders and Products tables, among others, have primary keys that use the AutoNumber data type. The Employees, Shippers, Products, and Suppliers tables use AutoNumber keys to identify the persons or objects to which the table’s records refer. Objects that are inherently sequentially numbered, such as checks, are ideal candidates for an AutoNumber key that corresponds to the check number, as mentioned in “Choosing Primary Key Codes” later in this chapter.

Another method of generating unique keys is by use of Globally Unique Identifiers (GUIDs), which also are called Universally Unique Identifiers (UUIDs). GUIDs are 16-byte computed binary numbers that are guaranteed to be unique locally and universally; no other computer in the world will duplicate a GUID. SQL Server’s uniqueidentifier data type is a GUID. Because GUIDs can’t represent a property of an object, such as a check number, GUID keys are called surrogate keys. You can’t select a GUID data type in Access’s Table Design mode.

Relationships come in the following three flavors:

  • One-to-many relationships represent connections between a single primary key value (the “one” side) and multiple instances of the same value in the foreign key field (the “many” side). One-to-many relationships commonly are identified by the number 1 and the infinity (∞) symbol, as in Figure 4.3. All the direct relationships between the tables in Figure 4.3 are one-to-many. One-to-many—also called many-to-one—relationships are by far the most common.
  • One-to-one relationships connect primary key values in two tables. You might think that the relationship between the Orders and Invoices tables could be one-to-one, but an order requires more than one invoice if one or more items are backordered and then shipped later. One-to-one relationships are uncommon.
  • Many-to-many relationships require three tables, one of which is called a linking table. The linking table must have two foreign keys, each of which has a many-to-one relationship with a primary key in two related tables. In the example of Figure 4.3, the Order Details table is the linking table for the many-to-many relationship between the Orders and Products tables. Many-to-many relationships also are called indirect relationships.

There are many other indirect relationships between the tables shown in Figure 4.3. For example, a many-to-many relationship exists between the Suppliers and Orders tables. In this case, Products and Order Details act as linking tables between the Suppliers and Orders tables.

The Relationships window displays the names of primary key fields in a boldface font. Notice in Figure 4.3 that the OrderID and ProductID field names are preceded by a key symbol. The OrderID and ProductID fields compose a composite primary key, which uniquely identifies an order line item. You can’t repeat the same combination of OrderID and ProductID; this precaution makes sense for products that have only one stock-keeping unit (SKU), such as for Aniseed Syrup, which comes only in a carton of 12 550ml bottles.


Access 2010’s multivalue field feature automatically generates a hidden linking table “under the covers.” Access 2007 introduced the multivalued field for compatibility with SharePoint lists.

The Oakmont.accdb sample database file in the \2010Samples\Oakmont folder of the downloadable code has a structure that differs from that of Northwind.accdb, but the design principles of the two databases are similar. OakmontSQL.mdf is an SQL Server 2008 database for use with ADP. ADP uses a special set of tools—called the project designer or da Vinci toolset in this book—for designing and managing SQL Server databases. The Oakmont files are course enrollment databases for a college. Figure 4.4 shows the Database Diagram window for the OakmontSQL database. The SQL Server Diagram window is similar to the Relationships window for Access’s traditional Access databases. The key and infinity symbols at the ends of each line represent the one and many sides, respectively, of the one-to-many relationships between the tables. Access and SQL Server databases store information on table relationships as an object within the database file.

Figure 4.4

The SQL Server Database Diagram window for the OakmontSQL database shows one-to-many relationships between primary key fields (identified by key symbols) and foreign key fields (infinity symbols).

This book uses the Access 2010 and SQL Server 2008 R2 versions of the Northwind and Oakmont sample databases in almost all examples. The tables of the Oakmont database have many more records than the Northwind tables. The large number of records in the Oakmont database makes it better suited than Northwind for predicting the performance of production Access and SQL Server database applications.


The one-product-entry-per-order restriction prevents shared use of the Order Details table as an invoice line items table. If you short-ship an order item on one invoice, you can’t add another record to the Order Details table when you ship the remaining quantity of the item. Microsoft didn’t add an Invoices table for Northwind Traders, probably because of the complexity of dealing with backorders and drop-shipments.

Conforming to Table Design Rules

Designing tables for relational databases follows a formalized procedure called normalization. Dr. Codd described the complete normalization process in his 1972 paper “Further Normalization of the Data Base Relational Model.” This paper isn’t an easy read; it’s steeped in the language of set theory and relational algebra. The sections that follow explain in common English the application of the normalization process to Access’s Northwind database.

You normalize tables in a series of steps called normal forms. Applying the normalization process is necessary to move spreadsheet-style data to relational tables. You also employ the normalization rules when designing a new database or analyzing existing databases. In specific cases, however, you might need to depart from strict adherence to normalization rules to retain a history of data values that change over time or to improve performance of a large database.

First Normal Form

First normal form requires tables to be flat and have no repeating or potentially repeating fields or groups of fields. A flat table is one in which every record has the same number of fields. In addition, a single field cannot contain multiple data values. Repeating fields must be moved to a related table. The first normal form is the most important of the normalization steps. If all your tables don’t meet the rules of first normal form, you are in big trouble.

Northwind’s Customers and Suppliers tables violate the no repeating fields rule. If a customer or supplier has more than one person involved in the ordering process, which is likely, the table would need repeating pairs of fields with different names, such as ContactName2 and ContactTitle2 or the like. To conform the Customers and Suppliers tables to first normal form, you must create two new tables—CustPers(sonel) and SuppPers(sonel), for example—to hold contact records. Including contact names in the Customers and Suppliers tables also violates third normal form, which is the subject of the later “Third Normal Form” section.

The ContactName field also violates the rule against multiple data values in a single field by combining given and family names. This isn’t a serious violation of first normal form, but it’s a good database design practice always to identify persons by given and family names in separate fields. When you create the new CustPers and SuppPers tables, separate the ContactName field into two fields, such as LastName and GivenName, which can include initials. You can then use a code similar to that for CustomerID for the ContactID field. For this example, the ContactID code is the first character of GivenName and the first four characters of LastName. Alternatively, you could assign an AutoNumber value to ContactID.

Figure 4.5 shows the first 19 of the 91 records of the CustPers table generated from the Customers table. The CustomerID field is required for a many-to-one relationship with the Customers table. Additional fields, such as Suffix, TitleOfCourtesy, Email(Address), Phone, and Fax, make the individual contact records more useful for creating mailing lists and integration with other applications, such as Microsoft Outlook.

Figure 4.5

You extract data for records of the CustPers table from the ContactName and ContactTitle fields of the Customers table. Separating given and last names simplifies generating a ContactID code to identify each record.

  • For more information on importing from Excel, see “Importing and Linking Spreadsheet Files,” p. XXX (Chapter 8).
  • To learn how to use Access action queries, see “Creating Action Queries to Append Records to a Table,” p. XXX (Chapter 13).

Figure 4.6 shows the Relationships window with the CustPers and SuppPers tables added to the Northwind database and their many-to-one relationships with the Customers and Suppliers tables, respectively.


You don’t need to retype the data to populate the CustPers and SuppPers tables. You can use Access to import the data from an Excel worksheet or text file, or use Access action queries (append and update) to handle this chore.

Figure 4.6

The Relationships window displays the many-to-one relationships between the Customers and CustPers tables and the Suppliers and SuppPers tables.

Second Normal Form

Second normal form requires that data in all non-key fields be fully dependent on the value of a primary key. The objective of second normal form is to avoid data redundancy in your tables.

Only Northwind’s Order Details linking table (see Figure 4.7) has a composite primary key (OrderID + ProductID). The UnitPrice field appears to violate the second normal form, because UnitPrice is a field of the Products table. UnitPrice values added to the Order Details table are dependent on the ProductID component of the composite primary key and not the OrderID component, so UnitPrice data is not fully dependent on the primary key. On first glance, the UnitPrice field appears to be redundant data. If you change the unit price of a product, it would appear that you would need to alter the UnitPrice value in every Order Details record for the product.

Figure 4.7

The Order Details linking table has a composite primary key consisting of the OrderID and ProductID fields.The Order Details table is an example of a situation in which you must retain what appears to be redundant information to maintain the integrity of historical data. Prices of products vary over time, so the price of a particular product is likely to change for orders placed on different dates. If the price of a product changes between the order and shipping (invoice) dates, the invoice reflects a different amount than the order. Despite the “Prices are subject to change without notice” boilerplate, customers become incensed if the invoice price is greater than the order price.

Eliminating the UnitPrice field from the Order Details table and looking up its value from the current price in the Products table also can cause accounting errors and distortion of historical reports based on bookings and sales data. Removing the UnitPrice data also violates the rules for the fifth normal form, explained later in this chapter.

Third Normal Form

Third normal form requires that data in all non-key fields of the table be fully dependent on the value of the primary key and describe only the object that the table represents. In other words, make sure that the table doesn’t include non-key fields that relate to some other object or process and includes non-key fields for descriptive data that isn’t contained in another related table.

As mentioned in the “First Normal Form” section, including contact information in the Customers and Products table violates third normal form rules. Contacts are persons, not customer or supplier organizations, and deserve their own related table that has attributes related to individuals.

Other examples of a common third normal form violation are the UnitsInStock and UnitsOnOrder fields of the Products table (see Figure 4.8). These fields aren’t fully dependent on the primary key value, nor do they describe the object; they describe how many of the product you have now and how many you might have if the supplier decides to ship your latest order. In a production order entry database, these values vary over time and must be updated for each sale of the product, each purchase order issued to the product’s supplier, and each receipt of the product. Purchases, receipts, and invoices tables are the most common source of the data on which the calculations are based.

Figure 4.8

The Products table’s UnitsInStock and UnitsOnOrder values must be calculated from data in tables that record purchases, receipts, and shipments of products.

Including UnitsInStock and UnitsOnOrder fields isn’t a serious violation of the normalization rules, and it’s not uncommon for product-based tables of order entry databases to include calculated values. The problem with calculated inventory values is the need to process a potentially large number of records in other tables to obtain an accurate current value.

Fourth Normal Form

Fourth normal form requires that tables not contain fields for two or more independent, multivalued facts. Loosely translated, this rule requires splitting tables that consist of lists of independent attributes. The Northwind and Oakmont databases don’t have an example of a fourth normal form violation, so the following is a fabricated example.


If you’re designing an order entry database, make sure to take into account committed inventory. Committed inventory consists of products in stock or en route from suppliers for which you have unfulfilled orders. If you decide to include inventory information in a products table, add a UnitsCommitted field.

One of the objectives of Human Resources departments is to match employee job skills with job openings. A multinational organization is likely to require a combination of specific job skills and language fluency for a particular assignment. A table of job skill types and levels exists with entries such as JP3 for Java Programmer–Intermediate, as well as language/fluency with entries such as TE5 for Telugu–Very Fluent. Therefore, the HR department constructs an EmplSkillLang linking table with the following foreign key fields: EmployeeID, SkillID, and LanguageID.

The problem with the linking table is that job skills and language fluency are independent facts about an employee. The ability to speak French has nothing to do with an employee’s ability to write Java code. Therefore, the HR department must split (decompose) the three-field table into two two-field linking tables: EmplSkills and EmplLangs.

Fifth Normal Form

Fifth normal form involves further reducing redundancy by creating multiple two-field tables from tables that have more than two foreign keys. The classic example is identifying independent sales agents who sell multiple products or categories of products for different companies. In this case, you have a table with AgentID, CompanyID, and ProductID or CategoryID. You can reduce redundancy—at the risk of making the database design overly complex—by creating three two-field tables: AgentCompany, CompanyProduct (or CompanyCategory), and AgentProduct (or AgentCategory). Database developers seldom attempt to normalize designs to fifth normal form because doing so requires adding many additional small tables to the database.


AutoNumber primary key values work well for serially numbered documents if you don’t allow records to be deleted. Adding a true-false (Boolean) field named Deleted and setting the value to true is one approach. This technique complicates queries against the tables, so you might consider moving deleted records to another table. Doing this lets you write a query to reconstruct all records for audit purposes.

Choosing Primary Key Codes

All Northwind and Oakmont tables use codes for primary key values, as do almost all production databases. The critical requirement is that the primary key value is unique to each record in the table. Following are some tips, many with online resources, to aid in establishing primary key codes:

  • Many types of tables—such as those for storing information on sales orders, invoices, purchase orders, and checks—are based on documents that have consecutive serial numbers, which are obvious choices for unique primary key values. In fact, most database designs begin with collecting and analyzing the paper forms used by an organization. If the table itself or programming code generates the consecutive number, make sure that every serial number is present in the table, even if an order is canceled or voided. Auditors are very suspicious of invoice and purchase order registers that skip serial numbers.
  • Packaged retail products sold in the United States have a globally unique 10-digit or longer Uniform Product Code (UPC). The UPC identifies both the supplier and the product’s SKU. The Uniform Code Council, Inc. (http://www.uc-council.org/) assigns supplier and product ID values, which are combined into linear bar codes for automated identification and data capture (AIDC). The European Article Number (EAN) is coordinated with the UPC to prevent duplication. The UPC/EAN code is a much better choice than Microsoft’s serially assigned number for the ProductID field.
  • Books have 10-digit and 13-digit International Standard Book Number (ISBN) codes that are unique throughout the world and, in North America, a UPC. ISBNs include a publisher prefix and book number, assigned to U.S. publishers by the U.S. ISBN Agency (http://www.bowker.com/standards/home/isbn/us/isbnus.html). ISBN Group Agencies assign codes for other countries. Canada has separate agencies for English- and French-language books. Either a UPC or ISBN field is suitable for the primary key of a North American books database, but ISBN is preferred if the code is for books only.
  • The North American Industry Classification System (NAICS, pronounced nakes) is replacing the U.S. Standard Industrial Classification (SIC) for categorizing organizations by their type of business. A six-digit primary key code for 18,000 classifications replaces the four-digit SIC code. Five of the six digits represent codes for classifications common to the United States, Canada, and Mexico. You can view a text file or purchase a CD-ROM of the NAICS codes and their SIC counterparts at http://www.naics.com/.
  • The U.S. Postal Service offers Address Information Systems (AIS) files for verifying addresses and corresponding ZIP/ZIP+4 codes. For more information on these files, go to http://www.usps.com and click the Address Quality link.
  • Social Security Numbers (SSNs) for U.S. residents are a possible choice for a primary key of an Employees table, but their disclosure compromises employees’ privacy. Large numbers of counterfeit Social Security cards having identical numbers circulate in the United States, making SSN even less attractive as a primary key field. The Oakmont database uses fictitious nine-digit SSNs for EmployeeID and StudentID fields. Most organizations assign each employee a sequential serial number. Sequential EmployeeID numbers can do double duty as seniority-level indicators.

Specifying a primary key for tables such as CustPers isn’t easy. If you use the five-character code based on first and last names for the primary key, you encounter the problem with potential duplication of CustomerID codes discussed earlier. In this case, however, common last names—Jones, Smith, and Anderson, for example—quickly result in duplicate values. Creating a composite primary key from CustomerID and ContactID is a potential solution; doing this increases the number of new contacts you can add for a company before inevitable duplicates occur. In most cases, it’s easier to use an AutoNumber key for all ID values.

Figure 4.9 shows the final design of the modified Northwind database with the added contact details tables. The tables of this database are included on the accompanying CD-ROM as Nwind04.mdb in the \2010Samples\Chaptr04 folder.

Figure 4.9

The final design of the expanded Northwind database with customer and supplier contact details tables added.

The modified Northwind database doesn’t qualify as a full-fledged customer relationship management (CRM) system, but the design is sufficiently flexible to serve as the model for a sales and purchasing database for a small-sized wholesale or retail concern.

Maintaining Data Integrity and Accuracy

When you add, modify, or delete table data, it’s important that the additions and changes you make to the data don’t conflict with the normalization rules that you used to create the database. One of the most vexing problems facing users of large RDBMs is “unclean data.” Over time, data entry errors and stray records accumulate to the point where obtaining accurate historical information from the database becomes difficult or impossible. Software vendors and database consultants have created a major-scale “data cleansing” business to solve the problem. You can avoid the time and expense of retroactive corrections to your data by taking advantage of Access and SQL Server features that aid in preventing errors during the data entry process.


You also must avoid changing the primary keys of or deleting one of two tables in a one-to-one relationship.

Referential Integrity

Maintaining referential integrity requires strict adherence to a single rule: Each foreign key value in a related table must correspond with a primary key value in a base (primary) table. This rule requires that the following types of modifications to data be prevented:

  • Adding a record on the many side of a one-to-many relationship without the existence of a related record on the one side of the relationship (for example, adding a record to the Orders table with a CustomerID value of BOGUS when no such customer record exists in the Customers table)
  • Deleting a record on the one side of a one-to-many relationship without first deleting all corresponding records on the many side of the relationship (for example, deleting Around the Horn’s Customers record when the Orders table contains records with AROUT as the CustomerID value)
  • Changing the value of a primary key field of a base table on which records in a related base or linking table depend, such as changing AROUT to ABOUT in the CustomerID field of the Customers table


Keypunch operators kept their eyes on the source documents, which gave rise to the term heads-down data entry. The term continues in common use to describe any data entry process in which the operator attention is fully devoted to adding or editing database records as quickly as possible.

  • Changing the value of a foreign key field in a linking table to a value that doesn’t exist in the primary key field of a base table (for example, changing AROUT to ABOUT in the CustomerID field for OrderID 10355)

A record in a related table that doesn’t have a corresponding foreign key value in the primary key of a base table is called an orphan record. For example, if the CustomerID value of a record in the Orders table is ABCDE and no ABCDE value exists in the CustomerID primary key field of the Customers table, there’s no way to determine which customer placed the order.

Access and SQL Server databases offer the option of automatically enforcing referential integrity when adding or updating data. Cascading updates and deletions are optional. If you specify cascading updates, changing the value of a primary key of a table makes the identical change to the foreign key value in related tables. Cascading deletions delete all related records with a foreign key that corresponds to the primary key of a record in a base table that you want to delete.

  • To learn more about enforcing referential integrity in Access databases, see “Establishing Relationships between Tables,” p. XXX (Chapter 5) and “Cascading Updates and Deletions,” p. XXX (Chapter 5).

Entity Integrity and Indexes

When you add new records to a base table, entity integrity assures that each primary key value is unique. Access and SQL Server ensure entity integrity by adding a no-duplicates index to the field you specify for the primary key. If duplicate values exist when you attempt to designate a field as the primary key, you receive an error message. You receive a similar error message if you enter a duplicate primary key value in the table.

  • For more information on Access indexes, see “Adding Indexes to Tables,” p. XXX (Chapter 5).

Indexes also speed searches of tables and improve performance when executing SQL statements that return data from fields of base and related tables.

Data Validation Rules and Check Constraints

Data entry errors are another major source of “unclean data.” In the days of punched-card data entry, keypunch operators typed the data, and verifiers, who usually worked during the succeeding shift, inserted the cards in a punched-card reader and repeated the keystrokes from the same source document. This process detected typographical errors, which the verifier corrected. Keypunch operators had no visual feedback during data entry, so typos were inevitable; video display terminals didn’t arrive until the mainframe era.

Rekeying data leads to low productivity, so most data entry applications support data validation rules designed to detect attempts to enter illegal or unreasonable values in fields. An example of a validation rule is preventing entry of a shipping date that’s earlier than the order date. The rule is expressed as an inequality: ShipDate >= OrderDate, which returns False if the rule, is violated. Similarly, UnitPrice > 0 prevents accidentally giving away a line item of an order.

Access tables and fields have a Validation Rule property that you set to the inequality expression. SQL Server calls validation rules check constraints. Both Access and SQL Server have a Validation Text property for which you specify the text to appear in an error message box when the entry violates the rule or constraint. It’s a more common practice when working with client/server databases to validate data in the front-end application before sending the entry to the back-end server. Detecting the error on the server and returning an error message requires a roundtrip from the client to the server. Server roundtrips generate quite a bit of network traffic and reduce data entry efficiency. One of the objectives of client/server front-end design is to minimize server round-tripping.

  • To learn more about Access’s validation methods, see “Validating Data Entry,” p. XXX
    (Chapter 6).


A database transaction occurs when multiple records in one or more tables must be added, deleted, or modified to complete a data entry operation. Adding an order or invoice that has multiple line items is an example of a transaction. If an order or invoice has five line items, but a network or database problem prevents adding one or more item records, the entire order or invoice is invalid. Maintaining referential integrity prevents adding line item records without a corresponding order or invoice record, but missing item records don’t violate integrity rules.


As mentioned earlier in the chapter, fields become columns and records become rows in a query. This terminology is an arbitrary convention of this book and not related to relational database design theory. The reason for the change in terminology is that a query’s rows and columns need not—and often do not—represent data values stored in the underlying tables. Queries can have columns whose values are calculated from multiple fields and rows with aggregated data, such as subtotals and totals.

Transaction processing (TP), also called online transaction processing (OLTP), solves the missing line item problem. Requiring TP for order entry, invoice processing, and similar multirecord operations enforces an all-or-nothing rule. If every individual update to the tables’ records occurs, the transaction succeeds (commits); if any update fails, changes made before the failure occurs are reversed (rolled back). Transaction processing isn’t limited to RDBMSs. Early mainframe databases offered TP and transaction monitors. IBM’s Customer Information and Control System (CICS, pronounced kicks) was one of the first transaction processing and monitoring systems, and it remains in widespread use today.

Access and SQL Server databases offer built-in TP features. Access has a Use Transactions property that you set to Yes to require TP for updates. SQL Server traditionally requires writing T-SQL statements—BEGIN TRANS, COMMIT TRANS, and ROLLBACK TRANS—to manage transactions, but Access 2010’s ADP forms have a new Batch Updates property that lets you enforce transactions without writing complex T-SQL statements.

  • For a brief description of the batch update feature introduced by Access 2007, see “Changes to ADP Features,” in Online Appendix B.

Displaying Data with Queries and Views

So far, this chapter has concentrated on designing relational databases and their tables, and adding or altering data. SQL SELECT queries return data to Access, but you don’t need to write SQL statements to display data in forms or print reports from the data. Access has built-in graphical tools to automatically write Access SQL for Access databases and T-SQL for SQL Server databases. Access’s query tools use a modern implementation of query-by-example (QBE), an IBM trademark. QBE is a simple method of specifying the tables and columns to view, how the data is sorted, and rows to include or exclude.

Linking related tables by their primary and foreign keys is called joining the tables. Early QBE programs required defining joins between tables; specifying table relationships automatically defines joins when you add records from two or more related Access or SQL Server tables.

Figure 4.10 is an example of Access’s QBE implementation for Access databases, called Query Design View. You add tables to the query—in this case, Northwind’s Customers, Orders, and Employees tables. As you add the tables, join lines indicate the relationships between them. You drag the field names for the query columns from the table lists in the upper pane to the Field row of the lower pane. You also can specify the name of a calculated column (Salesperson) and the expression to create the column values ([FirstName] & “” & [LastName]) in the Field row. The brackets surrounding FirstName and LastName designate that the values are field names.

Figure 4.10

Access’s Query Design view for Access databases uses graphical QBE to create queries you can store in the database.

Selecting Ascending or Descending in the Sort column orders the rows in left-to-right column priority. You can restrict the display to a particular set of values by adding an expression in the Criteria column.

Running the query returns the resultset, part of which is shown by Figure 4.11. You can save the query for later reuse as a named Access QueryDef(inition) object in the database.

Figure 4.11

These are the first 16 of the 408 rows of the query resultset returned by executing the query design of Figure 4.10.

SELECT Customers.CompanyName, Orders.OrderID, Orders.OrderDate,

         [FirstName] & “” & [LastName] AS Salesperson

   FROM Employees

      INNER JOIN (Customers

         INNER JOIN Orders

         ON Customers.CustomerID = Orders.CustomerID)

      ON Employees.EmployeeID = Orders.EmployeeID

   WHERE ((Year([OrderDate])=2006))

   ORDER BY Customers.CompanyName, Orders.OrderID;

It’s obvious that using QBE is much simpler than writing SELECT queries to concatenate field values, join tables, establish row selection criteria, and specify sort order. Access’s QBE features are powerful; many developers use Access to generate the SQL statements needed by Visual Basic, C++, and Java programs.


Access QBE automatically converts the query design of Figure 4.10 into the following Access SQL statement:

The da Vinci QBE tool for creating T-SQL views is similar to the Access Query Design view, but has an additional pane to display the T-SQL statement as you generate it. You add tables to the upper pane and drag field names to the Column cells of the middle pane. An SQL Server view is the client/server equivalent of an Access QueryDef. As with Access QueryDefs, you can execute a query on an SQL Server view.


T-SQL uses + rather than & to concatenate strings, uses a single quote (‘) as the string delimiter, and requires a numerical instead of a string criterion for the YEAR function. Here’s the T-SQL version of the preceding Access SQL statement after the SELECT and WHERE clauses have been tweaked:

The TOP modifier is needed to permit an ORDER BY clause in a view; prior to the addition of the TOP keyword in SQL Server 7.0, creating sorted views wasn’t possible. The da Vinci query parser adds the TOP 100 PERCENT modifier if an ORDER BY clause is present. However, TOP 100 PERCENT … ORDER BY doesn’t sort SQL Server 2005 views. Replacing 100 PERCENT with a large integer (<= 2147483647) sorts the view.

The dbo. prefix to table and field names is an abbreviation for database owner, the default owner for all SQL Server databases you create as a system administrator. Figure 4.12 shows the design of the T-SQL query generated by pasting the preceding statement into the da Vinci query pane.

Despite their common ANSI SQL-92 heritage, SQL Server won’t execute most Access SQL statements, and vice versa. Copying the preceding Access SQL statement to the Clipboard and pasting it into the SQL pane of the query designer for the NorthwindCS sample database doesn’t work. The da Vinci designer does its best to translate the Access SQL flavor into T-SQL when you paste, but you receive errors when you try to run the query.

SELECT TOP (2147483647) dbo.Customers.CompanyName,

      dbo.Orders.OrderID, dbo.Orders.OrderDate,

      dbo.Employees.FirstName + ‘ ‘ +

      dbo.Employees.LastName AS Salesperson

   FROM dbo.Employees

      INNER JOIN dbo.Customers

         INNER JOIN dbo.Orders

         ON dbo.Customers.CustomerID = dbo.Orders.CustomerID

      ON dbo.Employees.EmployeeID = dbo.Orders.EmployeeID

   WHERE (YEAR(dbo.Orders.OrderDate) = 2006)

   ORDER BY dbo.Customers.CompanyName, dbo.Orders.OrderID

  • For more information on the da Vinci toolset, see “Exploring SQL Server Views,” in online Chapter 27.
  • For detailed instructions on installing SQL Server Express and NorthwindCS.adp, see “Performing SQL Server Express Setup,” p. XXX (Chapter 1), and “Exploring the NorthwindCS Sample Project,” in online Chapter 27.

The Datasheet view of the SQL Server view generated by the preceding SQL statement is identical to the Access query’s Datasheet view shown in Figure 4.11.

Figure 4.12

Pasting an Access SQL statement into Access’s version of the da Vinci query design tool and making a few minor changes to the T-SQL statement results in an SQL Server view equivalent to the Access query of Figure 4.10.




Cty TNHH NOVA DIGITAL được thành lập dưới sự tham gia cố vấn và đầu tư từ những chuyên gia công nghệ cao Microsoft, VMware, IBM, EMC với định hướng phát triển trở thành một trong những đơn vị hàng đầu về Sản xuất phần mềm Giải pháp, Tư vấn giải pháp, Dịch vụ Triển khai các Giải pháp phần mềm CNTT trong Quản lý Doanh nghiệp và Điều hành các hệ thống giải pháp Điện toán đám mây.

Đội ngũ nhân sự có năng lực, kinh nghiệm trên 10 năm về triển khai và đào tạo công nghệ, sở hữu nhiều chứng chỉ Quốc tế quan trọng đảm bảo khả năng cạnh tranh trong việc phát triển dịch vụ Đào tạo và triển khai giải pháp CNTT tại Việt Nam và các nước ĐNÁ.


Công ty TNHH NOVA DIGITAL hoạt động trong lĩnh vực Sản xuất phẩm mềm Quản lý bằng CNTT, Dịch vụ triển khai và Đào tạo CNTT với thế mạnh nhiều năm kinh nghiệm:

  • Phát triển dịch vụ đào tạo chuyên ngành Công nghệ thông tin – Kinh tế và Viễn thông.
  • Đối tác Hợp tác cung cấp các giải pháp CNTT cho 3 Hiệp hội chuyên ngành:
    • Hiệp hội Chế biến và Xuất khẩu Thuỷ sản Việt Nam – VASEP (hơn 500 Doanh nghiệp thành viên trong các lĩnh vực XNK, Chế biến, Sản xuất, Ngân hàng, Thương mại Thuỷ sản).  website: http://www.vasep.com.vn/ 
    • Hiệp hội Gỗ và Lâm sản Việt Nam (hơn 300 Doanh nghiệp thành viên trong các lĩnh vực XNK, chế biến, sản xuất, Ngân hàng, Thương mại Gỗ – nội thất). website:  http://vietfores.org/
    • Hiệp hội Chế biến và xuất khẩu Chè Việt Nam – VITAS ( hơn 80 Doanh nghiệp thành viên trong các lĩnh vực XNK, chế biến, sản xuất, Ngân hàng, Thương mại Chè – ẩm thực Việt Nam).  Website: http://www.vitas.org.vn
  • Các giải pháp phần mềm tin học vào ứng dụng cho doanh nghiệp vừa và nhỏ như:
    • Office 365 Cloud.
    • Cung cấp các phần mềm bản quyền của Microsoft, VMware, Lạc Việt cho Doanh nghiệp Việt Nam.
    • Chứng thư số của Viettel ISP cho khai báo thuế Việt Nam.
    • Hệ thống SMS của Viettel Telecom cho Quản lý sản xuất – Kinh tế.
  • Cung cấp giải phải pháp phần mềm tin học ứng dụng trong trường học Phổ thông và Đại học.
    • Hệ thống SMS của Viettel Telecom cho Quản lý Trường Đại học.
    • Hệ thống SMS Học bạ cho Quản lý Trường Phổ thông.
  • Đối tác triển khai giải pháp duy nhất của Microsoft Live@edu tại Việt Nam.
    • Triển khai hệ thống Exchange Online, SharePoint Online, Forefront Protection for Exchange Online, Skydrive.
    • Tích hợp hệ thống ADSync với Windows Live ID và SSO.
    • Triển khai các giải pháp SSO giữa Moodle hoặc SharePoint On-premise với Outlook Live.
    • Dịch vụ Đào tạo Live@edu for Administrators và Giáo viên các Trường Phổ thông – Đại học.
  • Đối tác duy nhất triển khai nâng cấp Office365 Education của Microsoft tại Việt Nam.
    • Nâng cấp từ Microsoft Live@edu sang Office 365 cho 300 trường PTCS, 128 trường PTTH, 40 Trường CĐ- Trung học chuyên nghiệp, 37 Trường Đại học,  20 Viện và Sau Đại học tại 39 tỉnh thành Việt Nam.
    • Cung cấp phần mềm và triển khai các giải pháp tích hợp, khai thác Office 365 cho toàn bộ các Trường tại Việt Nam.
    • Dịch vụ đào tạo Office 365 gồm 3 môn chuẩn của Microsoft:
      • Course 70-321 Deploying Office 365.
      • Course 70-323 Administering Office 365 for SMB.
      • Course 74-324 End User Office365 training.
  • Đại lý chính thức AER và LAR của Microsoft cung cấp phần mềm giáo dục tại Việt Nam.
  • Đối tác đạo tạo University và Triển khai giải pháp Ảo hoá Chuyên nghiệp của VMware tại Việt Nam.
    • Đại lý sản phẩm phần mềm ảo hoá VMware.
    • Đối tác đào tạo uỷ quyền của VMware tại Việt Nam.
    • Đối tác triển khai Service Solution IT Professional of VMware.
  • Trung tâm thi chứng chỉ Công nghệ Thông tin Quốc tế Prometric, Pearson Vue.
  • Xây dựng trang web điện tử, xây dựng cổng thông tin Doanh nghiệp.



Để thực hiện các chức năng nhiệm vụ phát triển dịch vụ Đào tạo, định hướng kinh doanh, cung cấp các giải pháp ứng dụng CNTT, đảm bảo dịch vụ hỗ trợ khách hàng và duy trì hoạt động của Trung tâm một cách hiệu quả, NOVA Digital đã xây dựng một cơ cấu tổ chức một cách chặt chẽ, hợp lý bao gồm các phòng ban có mối quan hệ hỗ trợ và phối hợp đồng bộ tạo nên một sức mạnh tập thể. Đáp ứng và cung cấp các dịch vụ phục vụ khách hàng Doanh nghiệp một cách toàn diện, chu đáo.


CEO: Giám đốc điều hành

CIO: Giám đốc kỹ thuật.

CMO: Giám đốc quản lý đối tác.

CFO: Trưởng quản lý tài chính kế toán.

AM: Quản lý khách hàng.

CCO: Trưởng quản lý chăm sóc khách hàng.

CTO: Trưởng quản lý kỹ thuật và triển khai hỗ trợ kỹ thuật Khách hàng.



Chứng chỉ công nghệ Microsoft MCP:

          Chứng chỉ chuyên ngành cao cấp về hệ thống mạng (MCITP)

          Chứng chỉ chuyên gia CNTT về SharePoint 2010 (MCM).

          Chứng chỉ chuyên gia CNTT về Dynamic CRM.

          Chứng chỉ chuyên gia về Đào tạo CNTT của Microsoft (MCT)

Partner Microsoft Live@edu


Đối tác duy nhất triển khai Microsoft Live@edu tại Việt Nam.

Microsoft Licensing Sales Specialist LAR & AER

Chứng chỉ cấp phép bán hàng chuyên khối Doanh nghiệp, chính phủ và Giáo dục.


Microsoft Office Specialist

Chứng chỉ chuyên ngành về hoạt động nghiệp vụ văn phòng

Microsoft Learning Solution

Ủy quyền của Microsoft về cung cấp các giải pháp cho Giáo dục và Đào tạo

Microsoft SharePoint Platform

          Cung cấp giải pháp Cổng thông tin điện tử và Microsoft Learning Gateway theo nền tảng SharePoint.

          Gia công phần mềm, triển khai dịch vụ hỗ trợ kỹ thuật cho các Trường Quốc tế và Đại học như: Hanoi University of Pharmacy – http://www.hup.edu.vn , UNISHANOI: http://portal.unishanoi.org

Microsoft Dynamic CRM

Giải pháp triển khai hệ thống Chăm sóc khách hàng

Microsoft Business Intelligence

          Giải pháp Doanh nghiệp thông minh chuyên cung cấp giải pháp BI 2008, BI 2012 trên nền Windows Server 2008 R2, Windows Server 2012 cho Hải Quan Việt Nam và Hiệp hội CBXN TS VASEP, Hiệp hội Chè VITAS.

Đối tác của SourceCode


Chuyên triển khai giải pháp “Business Process Management Solution” cho Doanh nghiệp Viễn thông Viettel Telecom tại 64 tỉnh thành.

Khảo thí thi chứng chỉ Quốc tế


          Chuyên tổ chức thi chứng chỉ CNTT của Microsoft, IBM, WMware.


1.      Chương trình Microsoft Partner Program

          Đối tác của Microsoft phát triển mạng lưới và đánh giá, xác thực năng lực đối tác tại Việt Nam.

          Phát triển các gói sản phẩm, giải pháp cho các doanh nghiệp, đối tác.

          Đại lý chính thức cung cấp các phần mềm có bản quyền tại Việt Nam.

2.      Chương trình Microsoft LAR & AER (Microsoft Authorized Education Resller)

Tư vấn, cung cấp và đào tạo khai thác các phần mềm có bản quyền của Microsoft cho các đơn vị là Trường Đại học, Cao đẳng, THPT…

3.      Chương trình Live@edu và Office365 Cloud

Đối tác độc quyền triển khai cung cấp gói dịch vụ Microsoft Cloud miễn phí cho khối Giáo dục tại Việt Nam, Lào, Campuchia bao gồm:

          Hệ thống Email trực tuyến.

          Hệ thống cổng thông tin giáo dục trực tuyến.

          Hệ thống hội thảo trực tuyến.

          Hệ thống Microsoft Office trực tuyến.

          Hệ thống Dynamic CRM trực tuyến.

          Dịch vụ hỗ trợ, tư vấn và triển khai kỹ thuật Microsoft Cloud.

4.      Giải pháp phần mềm dựa trên nền tảng hạ tầng SharePoint và .Net Framework

          Cung cấp giải pháp cổng thông tin quản lý nội dung giáo trình, giáo án, trắc nghiệm cho khối giáo dục.

          Cung cấp giải pháp cổng thông tin quản lý nội dung giáo trình, giáo án, trắc nghiệm cho khối doanh nghiệp quản trị nhân sự.

5.      Giải pháp dịch vụ gia tăng trên di động (SMS Mobile)

Cung cấp giải pháp quản lý học sinh, sinh viên và phản hồi thông tin qua tổng đài nhắn tin thuê bao điện thoại di động.

6.      Phòng thi chứng chỉ Quốc tế được khảo thí ủy quyền của Prometric và Pearson Vue

Phòng thi đạt tiêu chuẩn Quốc tế được Prometric ủy quyền cho phép học viên thi và nhận các chứng chỉ chuyên ngành CNTT đạt chuẩn Quốc tế tại Việt Nam.

7.      Giải pháp ảo hóa hệ thống VMware

Đối tác độc quyền của VMware tại Việt Nam

          Tư vấn giải pháp.

          Triển khai hạ tầng.

          Đào tạo và chuyển giao công nghệ.

8.      Giải pháp phát triển dịch vụ trực tuyến trên nền Microsoft Cloud computing

Đối tác duy nhất tại Việt nam tư vấn, triển khai, đào tạo và chuyển giao công nghệ về các giải pháp trên nền Microsoft Cloud Apps.


Các thành viên xây dựng NOVA DIGITAL đều là những người có từ 10 – 16 năm kinh nghiệm triển khai trong các lĩnh vực:

1.      Dầu khí: PVOL

2.      Ngân hàng: Vietin Bank, VP Bank

3.      Bảo hiểm: Prudential, Manulife

4.      Vinamilk

5.      Đào tạo: RMIT University, de Heus, HUP, HUBT, HCMUT, NEU, HLU, Nhất Nghệ, DNU, HUESTAR.

6.      Hải Quan: Hải Quan Việt nam, FAO – FIIU – WCOO.

7.      Viễn Thông: Viettel Telecom.

8.      Truyền hình: VTC, Viettel Media, Mobiphone Media, PGM Senvang, HTC



Khách hàng Doanh nghiệp

Thời gian

Sản phẩm và dịch vụ cung cấp

Viettel Telecom

(64 tỉnh thành, 6000 người dùng).


Giải pháp Quản lý Quy trình về Hợp đồng Mua Bán

của  K2Workflow SourceCode trên nền SharePoint Office 2007 Server



Mô hình giải pháp SMS Mobile ứng dụng cho Nông thôn



Cổng thông tin chuyên ngành Thủy sản




Công thông tin nội bộ Hiệp hội Chè


Microsoft for Education

Từ 2008 đến nay

Chương trình Live@edu triển khai tại Việt Nam cho:

– 300 trường PTCS

– 128 trường PTTH

– 40 Trường CĐ- Trung học chuyên nghiệp

– 37 Trường Đại học

– 20 Viện và Sau Đại học tại 39 tỉnh thành Việt Nam.

– 15 Trường Quốc tế.



Trang học bạ trực tuyến Hocba.vn


Viettel CA


Cung cấp chữ ký số cho các ngành Thuế, Hải quan điện tử và các Doanh nghiệp thuê Hosting máy chủ.



Tư vấn và triển khai giải pháp Mobile SMS Gateway của Microsoft UPG tại nhà máy mía đường Nghệ An.

Bộ Nông nghiệp (MART)


Triển khai giải pháp thống kê giá nông nghiệp qua Mobile (Microsoft Project MIDAS)

Khách hàng GIÁO DỤC

Thời gian

Sản phẩm và dịch vụ cung cấp

Đại học Dược HN (Hanoi University of Pharmacy)

11.000 người dùng


Triển khai giải pháp hạ tầng Web hosting, Sharepoint portal, Learning Geatway, hội thảo trực tuyến bằng Microsoft Lync Online.

Website: http://www.hup.edu.vn

Kiểu dự án: Lai ghép điện toán đám mây

Đại học Văn Lang

25.000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, Moodle tích hợp Windows Live ID.

Website: http://www.vanlanguni.edu.vn/

Kiểu dự án: Lai ghép điện toán đám mây

Đại học Bách Khoa TP.HCM

35.000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PSA tích hợp Windows Live ID.

Website: http://www.hcmut.edu.vn/en

Kiểu dự án: Cloud and On-Premise

Đại học Tôn Đức Thắng

45.000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Website: http://english.tdt.edu.vn/ 

Kiểu dự án: Lai ghép điện toán đám mây

Đại học Đà nẵng

32.000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Triển khai Cổng thông tin Moodle Learning với Windows Live ID.

Website: http://www.dnu.edu.vn

Kiểu dự án: Lai ghép điện toán đám mây

Đại Học Dân lập Thăng Long

9000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Triển khai Cổng thông tin Joomla với Windows Live ID.

Website: http://thanglong.edu.vn/

Kiểu dự án: Lai ghép điện toán đám mây

Đại học Đông Đô

5000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Triển khai Cổng thông tin ASP.Net với Windows Live ID.

Website: http://www.dongdo.edu.vn

Kiểu dự án: Lai ghép điện toán đám mây

Đại học Quản trị Kinh Doanh Công nghệ HUBT

25.000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Triển khai Cổng thông tin Moodle Learning với Windows Live ID.

Website: http://www.hubt.edu.vn

Kiểu dự án: Lai ghép điện toán đám mây


Thời gian

Sản phẩm và dịch vụ cung cấp

Australian International School – Vietnam


1000 người dùng

2012 đến nay

Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Triển khai Cổng thông tin SharePoint 2010 với Windows Live ID và SSO.

Website: http://www.aisvietnam.com

Kiểu dự án: Lai ghép điện toán đám mây

Kinder World Group

2000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Triển khai Cổng thông tin Joomla với Windows Live ID và SSO.

Website: http://kinderworld.net/

Kiểu dự án: Lai ghép điện toán đám mây

the International School Ho Chi Minh City (ISHCMC)

3000 người dùng


Triển khai dịch vụ hạ tầng Outlook Live, PowerShell đồng bộ dữ liệu người dùng.

Triển khai Cổng thông tin Joomla với Windows Live ID và SSO.



1000 người dùng

2012 đến nay

Tư vấn giải pháp SharePoint, Exchange và triển khai Hạ dịch vụ quản lý hệ thống trọn gói




Doanh nghiệp mạnh về cung cấp giải pháp, thiết bị, dịch vụ  và phần mềm CNTT


Microsoft Small Business Specialist

Đối tác triển khai dịch vụ Office 365 cho Trường CĐ, ĐH và Doanh nghiệp

Đối tác chuyên triển khai và đào tạo các giải pháp Cổng thông tin SharePoint, BizTalk, SQL, Lync và Office Online.


Solution Service IT Professional

Đối tác chuyên triển khai giải pháp Ảo hoá vCenter & vCloud mạng Doanh nghiệp cho các Trường CĐ, ĐH và Doanh nghiệp.


Solution Service NAS Professional

Đối tác chuyên triển khai giải pháp Lưu trữ mạng nội bộ và Điện toán đám mây NAS to LAN & vCloud cho các Trường CĐ, ĐH và Doanh nghiệp.


 Service Provider SERVER & SAN Professional

Đối tác chuyên triển khai giải pháp Máy chủ Server & SAN cho các Trường CĐ, ĐH và Doanh nghiệp.



          Đối tác tư vấn và triển khai hệ thống phần mềm giải pháp dịch vụ khai báo Hải quan “E-Manifest Vietnam Customs”.

          Đối tác tư vấn và triển khai hệ thống Quản lý Nội dung số Truyền hình Viễn thông Viettel Media.


          Đối tác tư vấn và triển khai sản phẩm phần mềm Quản lý tài chính Khách hàng Doanh nghiệp ERP.


          Đối tác tư vấn và triển khai hệ thống Quản lý Nội dung số Truyền hình Tin tức VTC Media.

          Đối tác tư vấn và triển khai hạ tầng ảo hoá trong Đào tạo CNTT VTC Labs Management.


          Đối tác tư vấn và triển khai hệ thống Quản lý dịch vụ Ảo hoá Điện toán đám mây vCloud CMC IDC HCMC.


Doanh nghiệp tiên phong trong lĩnh vực Đào tạo CNTT



1.      Viện Đào tạo Công nghệ và Quản trị Robusta

2.      IPMAC.

3.      IT Academic Thang Long.

4.      NetPro IT Academic.

5.      Trung tâm CNTT Đại học Kinh doanh và Công nghệ Hà nội.

6.      Viện đào tạo CNTT & Viễn thông – Đại Học Mở Hà Nội.

7.      Viện Đào tạo Công nghệ sau đại học – Đại Học Bách Khoa Hà nội.

8.      Học viện CNTT – Kinh tế Quốc Dân.

9.      Trường Cao đẳng Công nghiệp Huế.

10.  Nhất Nghệ.


Đối tác Hiệp hội Doanh nghiệp Thông tấn


          14 năm Đối tác tư vấn và triển khai hỗ trợ nâng cao năng lực CNTT tại Hiệp hội Doanh nghiệp thủy sản Việt Nam (VASEP)


          4 năm Đối tác tư vấn và triển khai xây dựng, đào tạo năng lực quản lý nghiệp vụ văn phòng tại Hiệp hội Chè Việt Nam (VITAS)



          14 năm làm Đối tác tư vấn và hỗ trợ kỹ thuật  CNTT tại Doanh nghiệp sản xuất và chế biến đồ Gỗ nội thất trực thuộc Hội Gỗ Việt Nam


Chúng tôi cam kết

          Chất lượng dịch vụ là kim chỉ nam cho mọi hoạt động của chúng tôi do đó chúng tôi luôn tập trung để thỏa mãn yêu cầu của khách hàng với tinh thần phục vụ tận tụy và sự hiểu biết sâu sắc về nhu cầu đề ra.

          Cùng với đó chúng tôi không ngừng nâng cao năng lực công nghệ và cải tiến quy trình chất lượng nhằm cung cấp những sản phẩm và dịch vụ có chất lượng tốt nhất.

          Chân thành, chủ động trong việc xây dựng quan hệ đối tác để cùng phát triển.

          Đoàn kết nội bộ, nỗ lực phấn đấu vì một sự nghiệp Giáo dục tiến bộ.

          Tái đầu tư xã hội thông qua các hoạt động Giáo dục cộng đồng.

Chiến lược phát triển

          Chúng tôi không ngừng đầu tư để đảm bảo luôn đi trước và đón đầu công nghệ tiên tiến dựa trên những đối tác chiến lược lâu năm.

          Không ngừng mở rộng quan hệ đối tác tạo cơ hội phát triển lớn mạnh.

          Xây dựng mạng lưới khách hàng sâu rộng và bền vững.

          Đẩy mạnh công tác đào tạo, chuyển giao công nghệ với các hãng đối tác.

          Xây dựng chiến lược nhân sự ổn định dựa trên triết lý nhân bản sâu sắc.

          Hướng tới mục tiêu trở một trong những đơn vị tiên phong về cung cấp dịch vụ đào tạo và giải pháp công nghệ tại khu vực Châu Á Thái Bình Dương.