Download
1 / 12
120 likes | 163 Views
Database Design Overview. Basic Terms. Database DBMS File Record Field Cardinality Keys Index Pointer Referential Integrity Normalization Data Definition Language (DDL) Data Manipulation Language (DML) Data Control Language (DCL) Logging Junction Record.
E N D
Basic Terms • Database • DBMS • File • Record • Field • Cardinality • Keys • Index • Pointer • Referential Integrity • Normalization • Data Definition Language (DDL) • Data Manipulation Language (DML) • Data Control Language (DCL) • Logging • Junction Record
The Relational Model • Developed in early 1980’s (DR. Codd) • Effective with 1:1(one to one), 1:N (one to many) and N:M (many to many) • All Tables are a point of entry • Can discriminate to the Field level • Users must be aware of DB design to some degree • “Relationships” are dynamic • Allows “unlimited” tables per Physical Database (must take memory and disk into consideration) • Most Common Database 2 (DB/2 -Mainframe from IBM) Oracle, Sysbase SQL Server are popular PC databases • Programming language: Structured Query Language (SQL)
RelationalDesign • The goal of relational database design is to generate a set of schemas that allow us to • Store information without unnecessary redundancy. • Retrieve information easily (and accurately).
Normalization • There are three main normal forms, each with increasing levels of normalization: • First normal form (1NF): each field in a table contains different information. No multi-valued fields are permitted • Second normal form (2NF): no field values can be derived from another field outside of the primary key. All fields must support the full key value. • Third normal form (3FN): “transitive dependency” - prohibits multiple many-to-many relationships to occur in the same table.
Determining the Fields You Need To determine the fields in a table, decide what you need to know about the people, or things,or events recorded in the table. You can think of fields as characteristics of the table. Each record (or row) in the table contains the same set of fields or characteristics. For example, an address field in a customer table contains customers' addresses. Each record in the table contains data about one customer, and the address field contains the address for that customer. • Tips for Determining Fields • Relate each field directly to the subject of the table. A field that describes the subject of a different table belongs in the other table. Later, when you define relationships between your tables, you'll see how you can combine the data from fields in multiple tables. For now, make sure that each field in a table directly describes the subject of the table. If you find yourself repeating the same information in several tables, it's a clue that you have unnecessary fields in some of the tables. • Don't include derived or calculated data. In most cases, you don't want to store the result of calculations in tables. Instead, you can have the database manager perform the calculations when you want to see the result. Include all the information you need. It's easy to overlook important information. Return to the information you gathered in the first step of the design process. Look at your paper forms and reports to make sure all the information you have required in the past is included in your tables or can be derived from them. Think of the questions you will ask, do you have all of the fields to answer them. • Store information in its smallest logical parts. You may be tempted to have a single field for full names, or for product names along with product descriptions. If you combine more than one kind of information in a field, it's difficult to retrieve individual facts later. Try to break down information into logical parts; for example, create separate fields for first and last name, or for product name, category, and description.
Questions? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
