Normalization

dependent

An attribute whose value is determined by another attribute.

determinant

Attribute whose value determines another

Normalization

Evaluating and correcting table structures to minimize data redundancies. Reduces data anomalies Assigns attributes to tables based on determination It is about database design it is a process that we go through to ensure that we have a good database design.

Entity

person, place, thing, or event about which data will be collected and stored

(M:N)

1.A new relation is created to represent this relationship. We bridge/composite/associative entity. 2.The primary key for each of the participating entities is included in this new relation.

(1:M)

1.A relation is created for each of the two entities participating in the relationship. 2.The primary key attribute of the entity on the one-side of the relationship becomes a foreign key in the relation on the many-side of the relationship.

Relationship (supertype/subtype)

1.A separate relation is created for the supertype and each of its subtypes. 2.The primary key of the supertype is assigned to each subtype, as well as attributes that are unique to the subtype.

Second normal form (2NF)

1NF and no partial dependencies

Functional dependence (generalized definition) (4 of 5)

Attribute A determines attribute B (that is, B is functionally dependent on A) if all (generalized definition) of the rows in the table that agree in value for attribute A also agree in value for attribute B.

Normalization: How to Improve the Design

Evaluate PK assignments and naming conventions. •Refine attribute atomicity •Atomic attribute: cannot be further subdivided •Atomicity: characteristic of an atomic attribute(that we do not have multi-valued atts, we have single valued atts) •Identify new attributes and new relationships. •Refine primary keys as required for data granularity (making sure that it is a good PK, this is an opportunity to decide if we should use a NPK or a SPK) •Granularity: Level of detail represented by the values stored in a table's row •Maintain historical accuracy and evaluate using derived attributes Additional Slide Notes: (SOMETIMES IN NORMALIZATION the more we break it down in N amounts of NFs it can actually slow down performance due to have so many relations (tables). Which is why we stop at 3NF in this class.)

Boyce-Codd normal form (BCNF) (3of5)

Every determinant is a candidate key (special case of 3NF)

Derived data

Example: Storing STU_HRS and STU_CLASS (student classification) when STU_HRS determines STU_CLASS Rationale and Controls: Avoid extra join operations Program can validate classification (lookup) based on the student hours

Redundant data

Example: Storing ZIP and CITY attributes in the AGENT table when ZIP determines CITY Rationale and Controls: Avoid extra join operations Program can validate city (drop-down box) based on the zip code

Pre-aggregated data (also derived data)

Example: Storing the student grade point average (STU_GPA) aggregate value in the STUDENT table when this can be calculated from the ENROLL and COURSE tables Rationale and Controls: Avoid extra join operations Program computes the GPA every time a grade is entered or updated STU_GPA can be updated only via administrative routine

Information requirements

Example: Using a temporary denormalized table to hold report data; this is required when creating a tabular report in which the columns represent data that are stored in the table as rows Rationale and Controls: Impossible to generate the data required by the report using plain SQL No need to maintain table Temporary table is deleted once report is done Processing speed is not an issue

Primary Key

Never changing, Never Null, Uniquely Identifiable.

Surrogate Key Considerations

Used by designers when the primary key is: considered to be unsuitable, System-defined attribute Created an managed via the DBMS Have a numeric value which is automatically incremented for each new row

Partial Dependency (LecPPT6_S#16)

When a non-key attribute is determined by a part, not the whole, of a composite primary key. Occurs only when there is a composite key. Only part of the primary key is needed to determine other values.

The data-modeling checklist provides

a way for the designer to check that the ERD meets a set of minimum requirements

Attribute

characteristic of an entity

Normalization - The objective is to

ensure that each table conforms to the concept of a well-formed relation. (Conform = to act in accordance to follow the rules or tradition.

single-valued attribute

is an attribute that can have only a single value. For example, a person can have only one Social Security number, and a manufactured part can have only one serial number. (Keep in mind that a single-valued attribute is not necessarily a simple attribute. For instance, a part's serial number (such as SE-08-02-189935) is single-valued, but it is a composite attribute because it can be subdivided into the region in which the part was produced (SE), the plant within that region (08), the shift within the plant (02), and the part number (189935)).

simple attribute

is an attribute that cannot be subdivided For example, age, sex, and marital status would be classified as simple attributes. To facilitate detailed queries, it is wise to change composite attributes into a series of simple attributes.

A table is in 3NF when

it is in 2NF and contains no transitive dependencies

Normalization is an important part but

only a part of the design process

constraint

restriction placed on data to ensure data integrity

The larger the number of tables

the more additional I/O operations and processing logic you need to join them

Normalization is a technique

used to design tables in which data redundancies are minimized

Functional dependence

value of one or more attributes determines the value of one or more other attributes.

Functional Dependency

which means that the value of one or more attributes determines the value of one or more other attributes. Using this terminology, it would be correct to say that STU_NUM is the determinant and STU_LNAME is the dependent. STU_NUM functionally determines STU_LNAME, and STU_LNAME is functionally dependent on STU_NUM.

Normalization Process - 1NF_RULES

•1NF describes tabular format in which: •Each relation has a unique name •An entry at each row/column intersection is atomic (single-valued) - there are no repeating groups. •Each row is unique (identify primary key) •All attributes are dependent on the primary key •All relational tables satisfy 1NF requirements. Additional Slide Notes: (Most relational tables satisfy 1NF requirements.)

Conversion to First Normal Form (1NF) (2 of 3)

•1NF describes tabular format in which: •All key attributes are defined •There are no repeating groups in the table •All attributes are dependent on the primary key •All relational tables satisfy 1NF requirements •Some tables contain partial dependencies •Update, insertion, or deletion

Partial dependency: (5 of 5)

•functional dependence in which the determinant is only part of the primary key: •Assumption: one candidate key •Straight forward •Easy to identify

Repeating group

•group of multiple entries of same type can exist for any single key attribute occurrence •Reduces data redundancies

A table is in 2NF when

•it is in 1NF and contains no partial dependencies

Normalization is valuable because

•its use helps eliminate data redundancies •Evaluate PK assignments and naming conventions •Refine attribute atomicity •Identify new attributes and new relationships •Refine primary keys as required for data granularity •Maintain historical accuracy and evaluate using derived attributes

Denormalization

•produces a lower normal form •Results in increased performance and greater data redundancy

Conversion to First Normal Form (1NF) (1 of 3)

•Repeating group: group of multiple entries of same type can exist for any single key attribute occurrence: •Reduces data redundancies. •Three step procedure: •Eliminate the repeating groups. •Identify the primary key. •Identify all dependencies. •Dependency diagram: depicts all dependencies found within given table structure: •Helps to get an overview of all relationships among table's attributes. •Makes it less likely that an important dependency will be overlooked.

Conversion to Third Normal Form (3NF) (1 of 2)

•The data anomalies created by the database organization shown in Figure 6.4 are easily eliminated: •Make new tables to eliminate transitive dependencies •Reassign corresponding dependent attributes •Table is in 3NF when it: •Is in 2NF •Contains no transitive dependencies 2of2 book slide 17.

Normalization: Surrogate Key Considerations

•Used by designers when the primary key is considered to be unsuitable: •System-defined attribute •Created a managed via the DBMS •Have a numeric value which is automatically incremented for each new row •Considerations: •Be careful with surrogate keys, they can allow duplication of existing records. Additional Slide Notes: (Usually PKs numeric are preferred (damn got that wrong on Assessment 1), because they are faster than non-numeric for performance reasons. Be careful with SKs though, since they can allow duplicate of records as well. One way to fix that is to make Job description unique (those would be some constraints that we would add to our tables, when we are creating them. Some previous chapter/ppt talks about this, make sure to review it!)

The Need for Normalization

•Used while designing a new database structure •Analyzes the relationship among the attributes within each entity •Determines if the structure can be improved through normalization •Improves the existing data structure and creates an appropriate database design

What is the process for Normalization?

•Works one relation (table) at a time. •Identify the dependencies of a relation (table). •Progressively break the relation (table) into a set of new relations (tables). •Ensures all tables are in at least 3NF starting with 1NF, moving to 2NF, then to 3NF. Additional Slide Notes: (We go through our ERD, we create what is called a relational schema, and then we look at those relations, and identify any dependencies of a relation, etc. Follow the bullets on this slide step by step.)

A table is in 1NF when

•all key attributes are defined, and all remaining attributes are dependent on the primary key and we have eliminated all repeating groups.

Transitive dependency: (5 of 5)

•attribute is dependent on another attribute that is not part of the primary key •More difficult to identify among a set of data •Occur only when a functional dependence exists among nonprime attributes

A table that is not in 3NF may

•be split into new tables until all of the tables meet the 3NF requirements

Dependency diagram

•depicts all dependencies found within given table structure. •Helps to get an overview of all relationships among table's attributes. •Makes it less likely that an important dependency will be overlooked.

A table in 3NF might contain

multivalued dependencies that produce either numerous null values or redundant data

The Normalization Process (5 of 5)

Partial dependency & Transitive dependency

Granularity

-Level of detail represented by the values stored in a table's row

Atomic attribute

-cannot be further subdivided

Atomicity

-characteristic of an atomic attribute

How do we correct the dependencies to develop well-formed relations? Normalization Process.

1.Convert your ERD to a Relational Schema/Dependency Diagram. 2.Identify the primary keys and dependencies. 3.Convert the relations to 1NF. 4.Convert the relations to 2NF - remove partial dependencies. 5.Convert the relations to 3NF - remove transitive dependencies. Entity == table == relation Additional Slide Notes: Very important slide, these are the 5 steps we go through, we will elaborate on them further, but it wouldn't be a bad idea to make a quizlet slide on the order.

What is a well-formed relation?

1.Each table represents a single subject (one thing and one thing only). 2.Each row/column intersection contains only one value and not a group of values(no multivalued attributes, we want single). 3.No data item will be unnecessarily stored in more than one table(we are reducing redundancy). 4.All non-key attributes in a table are dependent on the primary key(Everything is dependent on the key the whole key and nothing but the key). 5.Each table has no insert, update, or delete anomalies.

(1:1)

1.The maximum cardinality determines how a relationship is represented. 2.The key from one relation is placed in the other as a foreign key. 3.Place foreign key to minimize NULL values.

Second normal form (2NF) (3of5)

1NF and no partial dependencies

Third normal form (3NF) (3of5)

2NF and no transitive dependencies

Third normal form (3NF)

2NF and no transitive dependencies. Additional Slide Notes: (Third is our ultimate goal for this course. Each higher form builds upon each other better improving. Remember normalization is built on determination and functional dependence, must know).

Transitive Dependency (LecPPT6_S#17)

A non-key attribute determines another non-key attribute. Occurs only when there is a dependency among non-key attributes.

Repeating groups (review)

A repeating set of columns, meaning a collection of columns containing similar kinds of values in a table, a single field containing an array of repeating values. (Repeating groups is new here, it is a repeating set of columns that has multiple data elements in it. VERY IMPORTANT especially in 1NF)

Normalization Process - 2NF_RULES.

A table is in 2NF when: •It is in 1NF. •Has no partial dependencies - every non-key attribute is functionally dependent on the full PK. •Questions to ask yourself: Is there a composite key? If no, then the table is in 2NF. If yes, are any of the non-key attributes dependent on part of composite key? If yes, then the table is not in 2NF. Are there non-key attributes in the table? If no, then the table is in 2NF. Additional Slide Notes: (Also, very important slide, basically all from 1NF>2NF...etc. Is there a composite key? If we don't have a Composite Key, we know that we don't have any partial dependencies, if we do there COULD BE a partial dependency).

Normalization Process - 3NF_RULES. (Note: not every table has transitive dependencies).

A table is in 3NF when it: •Is in 2NF. •Has no transitive dependencies - dependencies between 2 or more non-key attributes. •Questions to ask yourself: •Are there non-key attributes in the table? If yes, are any of the non-key attributes determined by other non-key attributes? If no, then the table is in 3NF.

composite attribute

An attribute that can be further subdivided to yield additional attributes (not to be confused with a composite). For example, a phone number such as 615-898- 2368 may be divided into an area code (615), an exchange number (898), and a four-digit code (2368). For example, the attribute ADDRESS can be subdivided into street, city, state, and zip code. Similarly, the attribute PHONE_ NUMBER can be subdivided into area code and exchange number

Multivalued attributes

An attribute that can have many values for a single entity occurrence. For example, an EMP_ DEGREE attribute might store the string "BBA, MBA, PHD" to indicate three different degrees held. For instance, a person may have several college degrees, and a household may have several different phones, each with its own number. Similarly, a car's color may be subdivided into many colors for the roof, body, and trim.

What are the criteria that we look for in good database design?

Controlled redundancy, we want to make sure that there is not insert, update, and delete anomalies. Making sure that when we are updating data, we are updating it once and only once. Inserting records, we are inserting records in a way that doesn't require us to, validate data or it doesn't require us to insert a bunch null values. When we delete data, we want to make sure we don't lose critical data, when we delete a record, we want to make sure that we don't violate any integrity rules. No anomalies = insert, update, delete. To sum, in a good database design we are looking for controlled redundancy and no anomalies. And the way we get there is the process of normalization.

Denormalized example

Customer (cust_id, name, street, city, state, zip) Normalized? Customer (cust_id, name, street, zipcode) Zips (zip code, city, state) A better choice? How often are you going to change the relationship between zip code and state? A perfect example here. Where we are storing information in our databases about addresses. Is this a 3NF? The answer is no, the reason being, is if we know the zip code, we can determine the city and state. You can see in the second is that we have a transitive example. City & State rely on zip code. But is this ultimately a better choice? Now for the second example if we want to know the customers city & state, we will be forced to always JOIN the two. Is that a bad thing? It all depends on how much DATA WE ARE WORKING WITH.

Rules for transforming ERDs into Relational Schemas.

Entities: 1. Each entity is transformed into a simple relation(getting us 1 step closer to our physical database). Remember the relations are known as tables. 2. Each attribute of the entity becomes an attribute of the relation. Weak entity: 1. A new relation is created corresponding to the weak entity. 2. The primary key of this relation consists of the primary key of the owner relation, plus the partial identifier of the weak entity type. We will have a composite key, because it's composed of the PK from the corresponding entity and its own. Multivalued attribute: 1. A new relation is created to replace the multivalued attribute. 2. The primary key of this new relation consists of two attributes(again a composite key): the primary key of the original relation, plus the multivalued attribute itself.

•Structural point of view of normal forms

Higher normal forms are better than lower normal forms. •Properly designed 3NF structures meet the requirement of fourth normal form (4NF)

Example(slide14)

How is this functional dependency? What are the determinants? Dependents? Cust_zip----->Cust_city, Cust_state Cust_lname, Cust_fname----->Cust_phone, Cust_address, Cust_zip Left side usually are determinants arrow signifies some sort of dependency and on the right-hand side of the arrows, those are the dependents. So, we can read the first one as a Customer zip code determines the city and the state, if we know the zip code, we can figure out city and state as they are unique to a zip code. Example 2: If I know the Customers first and last name we can determine the customers phone, address, and zip code, because data elements are unique to each customer.

Update anomalies(example).

If agent Leah F. Hahn has a new phone number, it must be entered in each of the CUSTOMER file records in which Ms. Hahn's phone number is shown. In this case, only four changes must be made. In a large file system, such a change might occur in hundreds or even thousands of records. Clearly, the potential for data inconsistencies are great.

Fully functional dependence (composite key) (4 of 5)

If attribute B is functionally dependent on a composite key A but not on any subset of that composite key, the attribute B is fully functionally dependent on A.

Insertion anomalies(example).

If only the CUSTOMER file existed, and you needed to add a new agent, you would also add a dummy customer data entry to reflect the new agent's addition. Again, the potential for creating data inconsistencies would be great.

Deletion anomalies(example).

If you delete the customers Amy B. O'Brian, George Williams, and Olette K. Smith, you will also delete John T. Okon's agent data. Clearly, this is not desirable.

What is normalization? (2 of 2)

Iterative process based on concept of determination. Focuses on relationships among attributes. Generates higher normal forms - First normal form (1NF), Second normal form (2NF), and Third normal form (3NF). Higher normal forms are better than lower normal forms. Normalization focuses on relationships as well, remember the relationships between entities, among attributes, etc. It generates higher normal forms, it's a process that we go through, and higher normal forms are better than lower.

Normalization Process - 2NF_STEPS.

Make new tables to eliminate partial dependencies. Reassign corresponding dependent attributes, leave other attributes intact.

Normalization Process - 3NF_STEPS.

Make new tables to eliminate transitive dependencies. For every transitive dependency, write its determinant as PK for new table Reassign corresponding dependent attributes

Is a fully normalized database always best?

Normalization means more relations. More relations mean more joins Joins are expensive operations: More CPU cycles More I/O Anomalies are not as likely in data that is read often, seldom updated. Normalization more important for transaction processing (data in) databases than analytical (information out) databases.

Normalization and Database Design (more information)

Normalization should be part of the design process Proposed entities must meet required the normal form before table structures are created. Principles and normalization procedures to be understood to redesign and modify databases: ERD is created through an iterative process Normalization focuses on the characteristics of specific entities Difficult to separate normalization process from ER modeling process

Normalization and Database Design

Normalization should be part of the design process: Proposed entities must meet required the normal form before table structures are created. Principles and normalization procedures to be understood to redesign and modify databases: ERD is created through an iterative process. Normalization focuses on the characteristics of specific entities.

What is normalization? (1 of 1)

Process used when designing new database structures to evaluate and correct table structures. Results in fewer data redundancies and data anomalies.

Denormalization (continued)

Produces a lower normal form, results in increased performance and greater data redundancy(definition). May make implementation more complex and maintenance more costly. May speed up retrieval, but slow down updates. Often uses additional storage because of repeated values, additional indexes.

Denormalization (2 of 2)

Redundant data (Figure 2.2) Derived data (Figure 3.28) Pre-aggregated data (also derived data) (Figure 3.28) Information requirements (Figures 6.17&6.18)

Rules for transforming ERDs into Relational Schemas(continued).

Relationships (1:M): 1. A relation is created for each of the two entities participating in the relationship. 2. The primary key attribute of the entity on the one-side of the relationship becomes a foreign key in the relation on the many-side of the relationship. (M:N): 1. A new relation is created to represent this relationship. We bridge/composite/associative entity. 2. The primary key for each of the participating entities is included in this new relation. (1:1): 1. The maximum cardinality determines how a relationship is represented. 2. The key from one relation is placed in the other as a foreign key. 3. Place foreign key to minimize NULL values. Relationship (supertype/subtype): 1. A separate relation is created for the supertype and each of its subtypes. 2. The primary key of the supertype is assigned to each subtype, as well as attributes that are unique to the subtype.

Determination

State in which knowing the value of one attribute makes it possible to determine the value of another. Establishes the role of a key based on the relationships among the attributes. Determination refresher: "If I know the value of one attribute, I can determine the value of another attribute."

First Normal Form (1NF) (3of5)

Table format, no repeating groups, and PK identified

First normal form (1NF)

Table format, no repeating groups, and PK identified

Higher-Level Normal Forms

Tables in 3NF perform suitably in business transactional databases. Higher-order normal forms are useful on occasion Two special cases of 3NF - (see supplemental slides): •Boyce-Codd normal form (BCNF) •Fourth normal form (4NF)

Normalization Process (Testing to make sure)

Tests for normalization: •Insertion anomaly. •Deletion anomaly. •Modification/update anomaly. •Ask the question, is the relation about 1 and only 1 thing? •Goal - Every non-key attribute (atts shown in blue slide 45) is dependent on "the key, the whole key, and nothing but the key"(this goes back to our partial/transitive dependencies).

What is a relational schema/dependency diagram?

Textual representation of the ER diagram showing dependencies. Defines the name of the table, name of each column. Identifies primary and foreign keys. Identifies relationships. Depicts(to show something) all dependencies found within given table structure. Additional Slide Notes: What we do is that we take our ER Diagram, then we convert it to a textual representation of our ER Diagrams (we get rid of all the boxes, and we just write the text and that is going to give us a relational schema, and then we draw some arrows showing those dependencies).

Dependent (review)

The attribute (or attributes) that depend on the determinant to be unique. The attribute on the right side of the equation.

Functional dependence (4 of 5)

The attribute B is fully functionally dependent on the attribute A if each value of A determines one and only one value of B. Example: PROJ_NUM S PROJ_NAME (read as PROJ_NUM functionally determines PROJ_NAME) In this case, the attribute PROJ_NUM is known as the determinant attribute, and the attribute PROJ_NAME is known as the dependent attribute.

Determinant (review)

The attribute that can be used to find the value of another attribute in the relation. The left-side of a functional dependency.

Determinant (A) & Dependent (B,C,D...etc.)

attribute whose value determines another (A) attribute whose value is determined by the other attribute (B,C,D)

Functional dependence (review)

The relationship (within the relation) that describes how the value of one attribute may be used to find the value of another attribute. Attribute A determines attribute B if all of the rows in the table that agree in value for attribute A also agree in value for attribute B. Example: PROJ_NUM à PROJ_NAME (read as PROJ_NUM functionally determines PROJ_NAME). In this case, the attribute PROJ_NUM is known as the determinant attribute, and the attribute PROJ_NAME is known as the dependent attribute.

Relationship

association among entities: One-to-many (1:M OR 1..*) Many-to-many (M:N or *..*) One-to-one (1:1 OR 1..1)

Data-Modeling Checklist (3 of 6)

•Attribute names: •Should be unique within the entity. •Should use the entity abbreviation as a prefix. •Should be descriptive of the characteristic. •Should use suffixes such as _ID, _NUM, or _CODE for the PK attribute. •Should not be a reserved word. •Should not contain spaces or special characters such as @, !, or & •Relationship names: •Should be active or passive verbs that clearly indicate the nature of the relationship.

Data-Modeling Checklist (5 of 6)

•Attributes: •Should be simple and single-valued (atomic data) •Should document default values, constraints, synonyms, and aliases. •Derived attributes should be clearly identified and include source(s). •Should not be redundant unless this is required for transaction accuracy, performance, or maintaining a history. •Non-key attributes must be fully dependent on the PK attribute. •Relationships: •Should clearly identify relationship participants. •Should clearly define participation, connectivity, and document cardinality.

Data-Modeling Checklist (1 of 6)

•Business rules: •Properly document and verify all business rules with the end users. •Ensure that all business rules are written precisely, clearly, and simply. (The business rules must help identify entities, attributes, relationships, and constraints.) •Identify the source of all business rules, and ensure that each business rule is justified, dated, and signed off by an approving authority

Conversion to Second Normal Form (2NF) (1 of 2)

•Conversion to 2NF occurs only when the 1NF has a composite primary key: •If the 1NF has a single-attribute primary key, then the table is automatically in 2NF. •The 1NF-to-2NF conversion is simple: •Make new tables to eliminate partial dependencies. •Reassign corresponding dependent attributes. •Table is in 2NF when it: •Is in 1NF. •Includes no partial dependencies. 2of2 is on book slide 15.

Data-Modeling Checklist (2 of 6)

•Data modeling: •Naming conventions: all names should be limited in length (database-dependent size) •Entity names: •Should be nouns that are familiar to business and should be short and meaningful •Should document abbreviations, synonyms, and aliases for each entity •Should be unique within the model •For composite entities, may include a combination of abbreviated names of the entities linked through the composite entity

Denormalization (1 of 2)

•Design goals: •Creation of normalized relations. •Processing requirements and speed. •Number of database tables expands: •Tables are decomposed to conform to normalization requirements. •Joining a larger number of tables: •Takes additional input/output (I/O) operations and processing logic. •Reduces system speed. •Defects in unnormalized tables: •Data updates are less efficient because tables are larger. •Indexing is more cumbersome. •No simple strategies for creating virtual tables known as views.

Data-Modeling Checklist (6 of 6)

•ER model: •Should be validated against expected processes: inserts, updates, and deletions. •Should evaluate where, when, and how to maintain a history. •Should not contain redundant relationships except as required (see attributes). •Should minimize data redundancy to ensure single-place updates. •Should conform to the minimal data rule: All that is needed is there, and all that is there is needed.

Three step procedure

•Eliminate the repeating groups •Identify the primary key •Identify all dependencies

Normalization Process - 1NF_ STEPS.

•Eliminate the repeating groups - group of multiple entries of same type can exist for any single key attribute occurrence •Identify the primary key •Identify all dependencies

The Normalization Process (2 of 5)

•Ensures that all tables are in at least 3NF: •Higher forms are not likely to be encountered in business environment •Works one relation at a time: •Identifies the dependencies of a relation (table) •Progressively breaks the relation up into a new set of relations

Data-Modeling Checklist (4 of 6)

•Entities: •Each entity should represent a single subject. •Each entity should represent a set of distinguishable entity instances. •All entities should be in 3NF or higher (Any entities below 3NF should be justified). •Granularity of the entity instance should be clearly defined. •PK should be clearly defined and support the selected data granularity.

Normal Forms (NF)

•First normal form (1NF) •Second normal form (2NF) •Third normal form (3NF)

The Normalization Process (1 of 5)

•Objective is to ensure that each table conforms to the concept of well-formed relations. •Each table represents a single subject. •Each row/column intersection contains only one value and not a group of values. •No data item will be unnecessarily stored in more than one table. •All nonprime attributes in a table are dependent on the primary key. •Each table has no insertion, update, or deletion anomalies.