{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}


Lab%208%20-%20Database%20Implementation - LAB 8 DATABASE...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
L AB 8 D A T A B A S E I M P L E M E N T A T I O N TABLE & RELATIONSHIP SETUP IN ACCESS Once you have a well-designed blueprint for your data, you can implement it in a database. In this chapter we will concentrate on implementing our employee training design in Microsoft Access. In the real world you may, in fact, make a different implementation decision. You may opt to implement your data design in XML or some other non-relationship database structure. If you decide that your proposed information system will be used simultaneously by more than about twenty-five people, Microsoft Access will in most cases not be the best choice. For those kinds of systems, an enterprise database system, such as Oracle, Microsoft SQL Server, or IBM DB2, would be much better. But for information systems that serve a single person, a small workgroup, or a low-traffic website, Microsoft Access can be a fine tool. Recommended Naming Conventions As you create your tables and fields in Microsoft Access or any database, it is a good idea to follow these naming conventions. Keep names short, but long enough to be descriptive. Do not include spaces inside your table or field names. If you include spaces you will have to hassle with square brackets ([]) when you use those tables or fields in SQL. Instead of spaces, just capitalize the first letter of each word. Avoid the use of symbols, such as #, because they will cause problems when referencing from programming code. Avoid the use of Access and SQL reserved words (such as Order, Select, or Case) and punctuation marks in table and field names. Be consistent in your use of abbreviations. If you abbreviate number as Num in one field name and No in another, you may confuse yourself later. Avoid generic field names. Don't name a field named ID or Date. Instead, use names like OrderID and OrderDate. Some database programmers like to name primary key and foreign key fields consistently so that they have the same name in both tables. Others prefer to name all fields after the table. For instance they might name field in the employee table. empID, empName, empDeptID. The empDeptID field would be a foreign key to CNIT 180: Lab 8 – Database Implementation Page 1
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
the deptID field in the department table, giving the primary key and foreign key different names. Whichever approach you take, it pays to be consistent. Some database programmers like to name all their tables beginning with tbl , all their queries beginning with qry , etc. The downside is that it is more typing. The upside is that you always know what kind of object you are working with. Some database programmers like to name all their fields beginning with an abbreviation of the data type. So you might have int EmpID ( integer ), txt Name ( text ), and dte Hire ( date ). This makes the names longer and leads to more typing.
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}