You have selected free tutorial of the Microsoft Corporation for the Microsoft Technology Associate (MTA) :
98-364: MTA: Database Fundamentals :
Module 1: Understanding Core Database Concepts :
Understand how data is stored in tables
Today’s advanced RDBMSs not only store your data, they also manage that data for you, restricting the kind of data that can go into the system, and facilitating getting data out of the system. If all you want is to tuck the data away somewhere safe, you could use just about any data storage system. RDBMSs allow you to go beyond the storage of the data into the realm of defining what that data should look like, or the business rules of the data. Tables are divided up into rows and columns. Each row must be able to stand on its own, without a dependency to other rows in the table. The row must represent a single, complete instance of the entity the table was created to represent. Each column in the row contains specific attributes that help define the instance. This may sound a bit complex, but it is actually very simple.
A database is typically a group of constructs that include at least a set of table objects and, more often than not, other objects, such as stored procedures and views that pertain to the particular grouping of data stored in the database’s tables. When you create your employee table, you also need to decide which attributes of the employee you want to store. For the purposes of this example, suppose that you have decided to store the employee ’ s last name, first name, Social Security number, department, extension, and hire date. The resulting table would look something like that shown in Figure
The data in the table would look something like that shown in Figure
Databases are made up of many things, but none is more central to the make-up of a database than tables are. A table can be thought of as equating to an accountant’s ledger or an Excel spreadsheet. It is made up of what is called domaindata (columns) and entitydata (rows). The actual data for the database is stored in the tables. table has a primary key that does not allow duplicate values for the StoreCode field. As long as we changed that one field, we could have left the rest of the columns alone and it would have taken the new row. To manage the data in your table efficiently, you need to be able to uniquely identify each individual row in the table. It is much more difficult to retrieve, update, or delete a single row if there is not a single attribute that identifies each row individually. In many cases, this identifier is not a descriptive attribute of the entity and referred as primary key. Each table can have only one primary key, which means that this key column is the
primary method for uniquely identifying individual rows. It doesn ’ t have to be the only mechanism for uniquely identifying individual rows; it is just the " primary " mechanism for doing so. Primary keys can never be null, and they must be unique. Primary keys can also be combinations of columns (though I ’ ll explain later why I am a firm believer that primary keys should typically be single - column keys). If you have a table where two columns in combination are unique, while either single column is not, you can combine the two columns as a single primary key, as illustrated in Figure above
As previously described, a table is a set of rows and columns used to represent an entity. Each row represents an instance of the entity. Each column in the row will contain at most one value that represents an attribute, or property, of the entity. In addition to deciding which attributes you want to maintain, you must also decide how to store those attributes. When you define columns for your tables, you must, at a minimum, define three things:
- The name of the column : Keep the names simple and intuitive (such as LastName or EmployeeID)
- The data type of the column : The data types of each column in a table must be implicitly compatible with the data type in the same relative column in the other table. Note that I’m not saying they have to be the same data type — they just have to be implicitly convertible (a conversion table that shows implicit versus explicit conversions ). When designing tables and choosing a data type for each column, try to be conservative and use the smallest, most efficient type possible. But at the same time, carefully consider the exception, however rare, and make sure that the chosen type will always meet these requirements.
- Whether the column can support null : All rows from the same table have the same set of columns. However, not all columns will necessarily have values in them. When you design your tables, you need to decide whether to allow a null condition to exist in your columns. Nulls can be allowed or disallowed on a column - by - column basis
Your Salary Above $ 66000... Click ...
Ohh! You want More.... be game developer of your choice $ 102000 ....