DOCSLIB.ORG

Database Normalization

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Database Normalization Database Normalization (Olav Dæhli – 2019) 25.10.2019 OD: Normalization 1 What is normalization and why normalize? • Normalization: A set of rules to decompose relations (tables) into smaller relations (tables), without loosing any data dependencies. • The reason for doing this, is to avoid: • duplicates, when not needed • redundant data, when not needed • unnecessary null values (because it makes selections and joins more difficult) • anomalies when updating data (when the same data have to be updated several places) 25.10.2019 OD: Normalization 2 Redundancy and Anomalies • Redundant data • Data that are unnecessary to store in the database • Duplicated data (the same information stored in several places) • Information that can be derived/calculated from other data • Age from BirthDate • Price inclusive VAT (Value Added Tax) calculated from price exclusive VAT • Anomalies • When the same data are stored in several places, update anomalies can occure 25.10.2019 OD: Normalization 3 Functional Dependency • X -> Y (means that Y is functionally dependent of X) • X and Y can be either one attribute (column) or a set of attributes (columns) (X1, X2, ... , Xi -> Y1, Y2, ... Yj ) • X is called a determinant, since X functionally determines Y. We have to know the meaning of X and Y to deside if a functional dependency exists. • Example: • PostalCode -> City (a specific postal code will always reference the same city). There exists a functional dependency between PostalCode and City, with PostalCode as a determinant. 25.10.2019 OD: Normalization 4 Functional Dependency (FD) • To know if a functional dependency exists, the data relations have to be analyzed by someone who knows the meaning of the data FD 1 FD 2 FD 3 25.10.2019 OD: Normalization 5 Superkey • A Superkey is one or more attributes (columns) in a relation (table), that uniquely determines all the attributes (columns) in the relation (table) • All the attributes together (in a table) will always be a Superkey. Example: • RegNumber, CarMake, Color, OwnerId, OwnerId, OwnerLastName, PostalCode, City • But lots of other combinations will also be Superkeys. Examples: • RegNumber, CarMake, Color, OwnerId, OwnerId, OwnerLastName, PostalCode, • RegNumber, OwnerId, PostalCode • RegNumber 25.10.2019 OD: Normalization 6 Candidate Key • A Candidate Key is a minimal Super Key • Criteria 1: If any attributes are removed from a Candidate Key, it will loose its characteristics as a Super Key • A Candidate Key is a «candidate» to be a Primary Key (A Primary Key is always selected amongst the Candidate Keys) • Criteria 2: Since it must have the ability to act as a Primary Key, it must be able to uniquely identify each and every row in the table 25.10.2019 OD: Normalization 7 Candidate Key - Examples • This is not a Candidate Key (but it is a Superkey): RegNumber, CarMake, Color, OwnerId, OwnerLastName, PostalCode, City • This is a Candidate Key: RegNumber • Case: PROJECTMEMBER (ProjectId, EmployeeId, HoursWorked) • This is a Candidate Key: ProjectId, EmployeeId • This is not Candidate Keys • ProjectId (neither a Superkey nor a Candidate Key) • EmployeeId (neither a Superkey nor a Candidate Key) • ProjectId, EmployeeId, HoursWorked (a Superkey, but not a Candidate Key) 25.10.2019 OD: Normalization 8 Using letters instead of column names • When the functional dependencies are described, letters (instead of column names) is often used to simplify the expression 25.10.2019 OD: Normalization 9 Normalization Criterias BCNF • No other 3NF functional • No transitive depen- 2NF functional dencies • No partial dependencies functional dependencies The goal is to 1NF achieve at least 3NF • Only «atomic» values for each attribute 25.10.2019 OD: Normalization 10 First normal form (1NF) • Criteria: Only «atomic» values for each attribute • Any multivalued attributes (repeating groups) have to be removed Example: Repeating groups (violates the 1NF-rule) 25.10.2019 OD: Normalization 11 First normal form (1NF) • One solution is to make one column for each car • Problems: 1) How many columns do we need? 2) It will result in many NULL-values 2) It will complicate search for data This is a bad solution. We want to expand the number of rows, not the number columns 25.10.2019 OD: Normalization 12 First normal form (1NF) - Normalization • Make a new table Primary Foreign Key • Move the repeating values to the new table Key • To preserve the functional dependency, the repeating values will act as Primary Key and a new attributt will act as a Foreign key to the original table 25.10.2019 OD: Normalization 13 Second normal form (2NF) • The table must satisfy 1NF • A Primary Key has to be chosen (amongst the Candidate Keys) • To qualify for 2NF, no non-key attributes can be dependant of only a part of the Primary Key (ie. «partial dependency» is not allowed) • NB! Only relevant when the Primary Key consists of more than one attribute (Combined Primary Key) Primary Key Partial Functional Dependency. C is dependant of a part of the Primary Key (B). This violates the 2NF-rule. 25.10.2019 OD: Normalization 14 Second normal form (2NF) - Normalization Split the table into two tables. Remove the partial dependency, and make it a new table B will become a Foreign Key 25.10.2019 OD: Normalization 15 Second normal form (2NF) - Example Splits the table into two tables without 2NF-violations CourseId will become a Foreign Key 25.10.2019 OD: Normalization 16 Third normal form (3NF) • The table must satisfy 2NF • A Primary Key has to be chosen (amongst the Candidate Keys) • No transitive functional dependencies from the Primary Key is allowed (which means that dependencies between non-key attributes will break the rule) Breaks the rule of the 3NF criteria A -> F and F -> G (and then: A -> G) Breaks the rule of is a Transitive Dependency the 3NF criteria 25.10.2019 OD: Normalization 17 Third normal form (3NF) - Normalization Still breaking Normalized the 3NF-rule to 3NF 1 2 3 Normalized Normalized to 3NF to 3NF 25.10.2019 OD: Normalization 18 Third normal form (3NF) - Example Still breaking Normalized the 3NF criteria to 3NF 1 2 3 Normalized Normalized to 3NF to 3NF 25.10.2019 OD: Normalization 19 Third normal form (3NF) - Example The result is that we end up with three 3NF-normalized tables, where all the original dependencies are preserved (through Foreign Keys): Foreign Key Foreign Key 25.10.2019 OD: Normalization 20 BCNF (Boyce Codd Normal Form) • This is very rare condition in practice, so we only take a brief look at it • BCNF is achieved by removing all other dependencies than specified in 2NF and 3NF • To meet the requirements of BCNF, every determinant in the relation (table) have to be a Candidate Key • BCNF-violation can only occur in relations (tables) with more than one composite Candidate Key, where at least one common attribute overlaps. In other cases, 3NF and BCNF will be equivalent 25.10.2019 OD: Normalization 21 BCNF - Example • Goal: A database for arranging parent-teacher conferences at a school • Table Name: PARENT_TEACHER_CONFERENCE • Constraint: A teacher is always assigned the same room for all the conferences listed on the same date. Various teachers can use the same room. • Table before normalization: We start with the Universal Relation: (All the data we want to register) Date Time Teacher Pupil Room 25.10.2019 OD: Normalization 22 BCNF – Example: Identifing dependencies Candidate Key 1 (CK1) Candidate Key 2 (CK2) CK2 CK1 A third functional dependency which is not a Candidate Key. This violates the BCNF-criteria. 25.10.2019 OD: Normalization 23 BCNF – Example: Normalization-solution Remove the attributes involved in the functional dependency that violates BCNF, and place them in a new, separate table The remaining part becomes the second table Both dependencies is now Candidate Keys and no other dependencies exist in the relation (table) 25.10.2019 OD: Normalization 24 Normalization - A step by step-strategy 1) Start with the Universal Relation (all the attributes from all the tables) 2) Analyze the data to reveal all the functional dependencies 3) Remove any repeating values (1NF-criteria) 4) Identify all Candidate Keys 5) Select a Primary Key 6) Remove any partial dependencies (to achieve 2NF) 7) Remove any transitive dependencies (to achieve 3N) 8) Remove any remaining dependencies (to achieve BCNF) 25.10.2019 OD: Normalization 25 Problems with Normalization • Normalization leads to smaller tables • Smaller tables (and more foreign keys) complicates inserting data • Normalization increases the need for joining tables when performing queries against the table. • More duplicated data, because of more foreign keys (but less redundancy of the same reason, which is positive) • 3NF is often the goal (because the rules of BCNF is more complicated to maintain than the rules of 3NF) 25.10.2019 OD: Normalization 26.
Load more

Recommended publications
  • Keys Are, As Their Name Suggests, a Key Part of a Relational Database
    The key is defined as the column or attribute of the database table. For example if a table has id, name and address as the column names then each one is known as the key for that table. We can also say that the table has 3 keys as id, name and address. The keys are also used to identify each record in the database table . Primary Key:- • Every database table should have one or more columns designated as the primary key . The value this key holds should be unique for each record in the database. For example, assume we have a table called Employees (SSN- social security No) that contains personnel information for every employee in our firm. We’ need to select an appropriate primary key that would uniquely identify each employee. Primary Key • The primary key must contain unique values, must never be null and uniquely identify each record in the table. • As an example, a student id might be a primary key in a student table, a department code in a table of all departments in an organisation. Unique Key • The UNIQUE constraint uniquely identifies each record in a database table. • Allows Null value. But only one Null value. • A table can have more than one UNIQUE Key Column[s] • A table can have multiple unique keys Differences between Primary Key and Unique Key: • Primary Key 1. A primary key cannot allow null (a primary key cannot be defined on columns that allow nulls). 2. Each table can have only one primary key. • Unique Key 1. A unique key can allow null (a unique key can be defined on columns that allow nulls.) 2.
    [Show full text]
  • Database Design Solutions
    spine=1.10" Wrox Programmer to ProgrammerTM Wrox Programmer to ProgrammerTM Beginning Stephens Database Design Solutions Databases play a critical role in the business operations of most organizations; they’re the central repository for critical information on products, customers, Beginning suppliers, sales, and a host of other essential information. It’s no wonder that Solutions Database Design the majority of all business computing involves database applications. With so much at stake, you’d expect most IT professionals would have a firm understanding of good database design. But in fact most learn through a painful process of trial and error, with predictably poor results. This book provides readers with proven methods and tools for designing efficient, reliable, and secure databases. Author Rod Stephens explains how a database should be organized to ensure data integrity without sacrificing performance. He shares procedures for designing robust, flexible, and secure databases that provide a solid foundation for all of your database applications. The methods and techniques in this book can be applied to any database environment, including Oracle®, Microsoft Access®, SQL Server®, and MySQL®. You’ll learn the basics of good database design and ultimately discover how to design a real-world database. What you will learn from this book ● How to identify database requirements that meet users’ needs ● Ways to build data models using a variety of modeling techniques, including Beginning entity-relational models, user-interface models, and
    [Show full text]
  • Data Definition Language
    1 Structured Query Language SQL, or Structured Query Language is the most popular declarative language used to work with Relational Databases. Originally developed at IBM, it has been subsequently standard- ized by various standards bodies (ANSI, ISO), and extended by various corporations adding their own features (T-SQL, PL/SQL, etc.). There are two primary parts to SQL: The DDL and DML (& DCL). 2 DDL - Data Definition Language DDL is a standard subset of SQL that is used to define tables (database structure), and other metadata related things. The few basic commands include: CREATE DATABASE, CREATE TABLE, DROP TABLE, and ALTER TABLE. There are many other statements, but those are the ones most commonly used. 2.1 CREATE DATABASE Many database servers allow for the presence of many databases1. In order to create a database, a relatively standard command ‘CREATE DATABASE’ is used. The general format of the command is: CREATE DATABASE <database-name> ; The name can be pretty much anything; usually it shouldn’t have spaces (or those spaces have to be properly escaped). Some databases allow hyphens, and/or underscores in the name. The name is usually limited in size (some databases limit the name to 8 characters, others to 32—in other words, it depends on what database you use). 2.2 DROP DATABASE Just like there is a ‘create database’ there is also a ‘drop database’, which simply removes the database. Note that it doesn’t ask you for confirmation, and once you remove a database, it is gone forever2. DROP DATABASE <database-name> ; 2.3 CREATE TABLE Probably the most common DDL statement is ‘CREATE TABLE’.
    [Show full text]
  • Normalization of Databases
    Normalization of databases Database normalization is a technique of organizing the data in the database. Normalization is a systematic approach of decomposing tables to eliminate data redundancy and undesirable characteristics such as insertion, update and delete anomalies. It is a multi-step process that puts data in to tabular form by removing duplicated data from the relational table. Normalization is used mainly for 2 purpose. - Eliminating redundant data - Ensuring data dependencies makes sense. ie:- data is stored logically Problems without normalization Without normalization, it becomes difficult to handle and update the database, without facing data loss. Insertion, update and delete anomalies are very frequent is databases are not normalized. Example :- S_Id S_Name S_Address Subjects_opted 401 Adam Colombo-4 Bio 402 Alex Kandy Maths 403 Steuart Ja-Ela Maths 404 Adam Colombo-4 Chemistry Updation Anomaly – To update the address of a student who occurs twice or more than twice in a table, we will have to update S_Address column in all the rows, else data will be inconsistent. Insertion Anomaly – Suppose we have a student (S_Id), name and address of a student but if student has not opted for any subjects yet then we have to insert null, which leads to an insertion anomaly. Deletion Anomaly – If (S_id) 401 has opted for one subject only and temporarily he drops it, when we delete that row, entire student record will get deleted. Normalisation Rules 1st Normal Form – No two rows of data must contain repeating group of information. Ie. Each set of column must have a unique value, such that multiple columns cannot be used to fetch the same row.
    [Show full text]
  • KB SQL Database Administrator Guide a Guide for the Database Administrator of KB SQL
    KB_SQL Database Administrator Guide A Guide for the Database Administrator of KB_SQL © 1988-2019 by Knowledge Based Systems, Inc. All rights reserved. Printed in the United States of America. No part of this manual may be reproduced in any form or by any means (including electronic storage and retrieval or translation into a foreign language) without prior agreement and written consent from KB Systems, Inc., as governed by United States and international copyright laws. The information contained in this document is subject to change without notice. KB Systems, Inc., does not warrant that this document is free of errors. If you find any problems in the documentation, please report them to us in writing. Knowledge Based Systems, Inc. 43053 Midvale Court Ashburn, Virginia 20147 KB_SQL is a registered trademark of Knowledge Based Systems, Inc. MUMPS is a registered trademark of the Massachusetts General Hospital. All other trademarks or registered trademarks are properties of their respective companies. Table of Contents Preface ................................................. vii Purpose ............................................. vii Audience ............................................ vii Conventions Used in this Manual ...................................................................... viii The Organization of this Manual ......................... ... x Additional Documentation .............................. xii Chapter 1: An Overview of the KB_SQL User Groups and Menus ............................................................................................................
    [Show full text]
  • Database Normalization
    Outline Data Redundancy Normalization and Denormalization Normal Forms Database Management Systems Database Normalization Malay Bhattacharyya Assistant Professor Machine Intelligence Unit and Centre for Artificial Intelligence and Machine Learning Indian Statistical Institute, Kolkata February, 2020 Malay Bhattacharyya Database Management Systems Outline Data Redundancy Normalization and Denormalization Normal Forms 1 Data Redundancy 2 Normalization and Denormalization 3 Normal Forms First Normal Form Second Normal Form Third Normal Form Boyce-Codd Normal Form Elementary Key Normal Form Fourth Normal Form Fifth Normal Form Domain Key Normal Form Sixth Normal Form Malay Bhattacharyya Database Management Systems These issues can be addressed by decomposing the database { normalization forces this!!! Outline Data Redundancy Normalization and Denormalization Normal Forms Redundancy in databases Redundancy in a database denotes the repetition of stored data Redundancy might cause various anomalies and problems pertaining to storage requirements: Insertion anomalies: It may be impossible to store certain information without storing some other, unrelated information. Deletion anomalies: It may be impossible to delete certain information without losing some other, unrelated information. Update anomalies: If one copy of such repeated data is updated, all copies need to be updated to prevent inconsistency. Increasing storage requirements: The storage requirements may increase over time. Malay Bhattacharyya Database Management Systems Outline Data Redundancy Normalization and Denormalization Normal Forms Redundancy in databases Redundancy in a database denotes the repetition of stored data Redundancy might cause various anomalies and problems pertaining to storage requirements: Insertion anomalies: It may be impossible to store certain information without storing some other, unrelated information. Deletion anomalies: It may be impossible to delete certain information without losing some other, unrelated information.
    [Show full text]
  • Database Models
    Enterprise Architect User Guide Series Database Models The Sparx Systems Enterprise Architect Database Builder helps visualize, analyze and design system data at conceptual, logical and physical levels, generate database objects from a model using customizable Transformations, and reverse engineer a DBMS. Author: Sparx Systems Date: 16/01/2019 Version: 1.0 CREATED WITH Table of Contents Database Models 4 Data Modeling Overview 5 Conceptual Data Model 7 Logical Data Model 8 Entity Relationship Diagrams (ERDs) 9 Physical Data Models 13 Database Modeling 15 Create a Data Model from a Model Pattern 16 Create a Data Model Diagram 18 Example Data Model Diagram 20 The Database Builder 22 Opening the Database Builder 24 Working in the Database Builder 26 Columns 30 Create Database Table Columns 31 Delete Database Table Columns 33 Reorder Database Table Columns 34 Constraints/Indexes 35 Database Table Constraints/Indexes 36 Primary Keys 39 Database Indexes 42 Unique Constraints 45 Foreign Keys 46 Check Constraints 50 Table Triggers 52 SQL Scratch Pad 54 Database Compare 56 Execute DDL 62 Database Objects 65 Database Tables 66 Create a Database Table 68 Database Table Columns 70 Create Database Table Columns 71 Delete Database Table Columns 73 Reorder Database Table Columns 74 Working with Database Table Properties 75 Set the Database Type 76 Set Database Table Owner/Schema 77 Set MySQL Options 78 Set Oracle Database Table Properties 79 Database Table Constraints/Indexes 80 Primary Keys 83 Non Clustered Primary Keys 86 Database Indexes 87 Unique
    [Show full text]
  • Ms Sql Server Alter Table Modify Column
    Ms Sql Server Alter Table Modify Column Grinningly unlimited, Wit cross-examine inaptitude and posts aesces. Unfeigning Jule erode good. Is Jody cozy when Gordan unbarricade obsequiously? Table alter column, tables and modifies a modified column to add a column even less space. The entity_type can be Object, given or XML Schema Collection. You can use the ALTER statement to create a primary key. Altering a delay from Null to Not Null in SQL Server Chartio. Opening consent management ebook and. Modifies a table definition by altering, adding, or dropping columns and constraints. RESTRICT returns a warning about existing foreign key references and does not recall the. In ms sql? ALTER to ALTER COLUMN failed because part or more. See a table alter table using page free cloud data tables with simple but block users are modifying an. SQL Server 2016 introduces an interesting T-SQL enhancement to improve. Search in all products. Use kitchen table select add another key with cascade delete for debate than if column. Columns can be altered in place using alter column statement. SQL and the resulting required changes to make via the Mapper. DROP TABLE Employees; This query will remove the whole table Employees from the database. Specifies the retention and policy for lock table. The default is OFF. It can be an integer, character string, monetary, date and time, and so on. The keyword COLUMN is required. The table is moved to the new location. If there an any violation between the constraint and the total action, your action is aborted. Log in ms sql server alter table to allow null in other sql server, table statement that can drop is.
    [Show full text]
  • 3 Data Definition Language (DDL)
    Database Foundations 6-3 Data Definition Language (DDL) Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Roadmap You are here Data Transaction Introduction to Structured Data Definition Manipulation Control Oracle Query Language Language Language (TCL) Application Language (DDL) (DML) Express (SQL) Restricting Sorting Data Joining Tables Retrieving Data Using Using ORDER Using JOIN Data Using WHERE BY SELECT DFo 6-3 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. 3 Data Definition Language (DDL) Objectives This lesson covers the following objectives: • Identify the steps needed to create database tables • Describe the purpose of the data definition language (DDL) • List the DDL operations needed to build and maintain a database's tables DFo 6-3 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. 4 Data Definition Language (DDL) Database Objects Object Description Table Is the basic unit of storage; consists of rows View Logically represents subsets of data from one or more tables Sequence Generates numeric values Index Improves the performance of some queries Synonym Gives an alternative name to an object DFo 6-3 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. 5 Data Definition Language (DDL) Naming Rules for Tables and Columns Table names and column names must: • Begin with a letter • Be 1–30 characters long • Contain only A–Z, a–z, 0–9, _, $, and # • Not duplicate the name of another object owned by the same user • Not be an Oracle server–reserved word DFo 6-3 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. 6 Data Definition Language (DDL) CREATE TABLE Statement • To issue a CREATE TABLE statement, you must have: – The CREATE TABLE privilege – A storage area CREATE TABLE [schema.]table (column datatype [DEFAULT expr][, ...]); • Specify in the statement: – Table name – Column name, column data type, column size – Integrity constraints (optional) – Default values (optional) DFo 6-3 Copyright © 2015, Oracle and/or its affiliates.
    [Show full text]
  • Relational Database Fundamentals
    05_04652x ch01.qxp 7/10/06 1:45 PM Page 7 Chapter 1 Relational Database Fundamentals In This Chapter ᮣ Organizing information ᮣ Defining database ᮣ Defining DBMS ᮣ Comparing database models ᮣ Defining relational database ᮣ Considering the challenges of database design QL (pronounced ess-que-ell, not see’qwl) is an industry-standard language Sspecifically designed to enable people to create databases, add new data to databases, maintain the data, and retrieve selected parts of the data. Various kinds of databases exist, each adhering to a different conceptual model. SQL was originally developed to operate on data in databases that follow the relational model. Recently, the international SQL standard has incorporated part of the object model, resulting in hybrid structures called object-relational databases. In this chapter, I discuss data storage, devote a section to how the relational model compares with other major models, and provide a look at the important features of relational databases. Before I talk about SQL, however, I need to nail down what I mean by the term database. Its meaning has changed as computers have changed the way people record and maintain information. COPYRIGHTED MATERIAL Keeping Track of Things Today, people use computers to perform many tasks formerly done with other tools. Computers have replaced typewriters for creating and modifying documents. They’ve surpassed electromechanical calculators as the best way to do math. They’ve also replaced millions of pieces of paper, file folders, and file cabinets as the principal storage medium for important information. Compared to those old tools, of course, computers do much more, much faster — and with greater accuracy.
    [Show full text]
  • 8 the Relational Data Model
    CHAPTER 8 ✦ ✦ ✦ ✦ The Relational Data Model One of the most important applications for computers is storing and managing information. The manner in which information is organized can have a profound effect on how easy it is to access and manage. Perhaps the simplest but most versatile way to organize information is to store it in tables. The relational model is centered on this idea: the organization of data into collections of two-dimensional tables called “relations.” We can also think of the relational model as a generalization of the set data model that we discussed in Chapter 7, extending binary relations to relations of arbitrary arity. Originally, the relational data model was developed for databases — that is, Database information stored over a long period of time in a computer system — and for database management systems, the software that allows people to store, access, and modify this information. Databases still provide us with important motivation for understanding the relational data model. They are found today not only in their original, large-scale applications such as airline reservation systems or banking sys- tems, but in desktop computers handling individual activities such as maintaining expense records, homework grades, and many other uses. Other kinds of software besides database systems can make good use of tables of information as well, and the relational data model helps us design these tables and develop the data structures that we need to access them efficiently. For example, such tables are used by compilers to store information about the variables used in the program, keeping track of their data type and of the functions for which they are defined.
    [Show full text]
  • DBMS Keys Mahmoud El-Haj 13/01/2020 The
    DBMS Keys Mahmoud El-Haj 13/01/2020 The following is to help you understand the DBMS Keys mentioned in the 2nd lecture (2. Relational Model) Why do we need keys: • Keys are the essential elements of any relational database. • Keys are used to identify tuples in a relation R. • Keys are also used to establish the relationship among the tables in a schema. Type of keys discussed below: Superkey, Candidate Key, Primary Key (for Foreign Key please refer to the lecture slides (2. Relational Model). • Superkey (SK) of a relation R: o Is a set of attributes SK of R with the following condition: . No two tuples in any valid relation state r(R) will have the same value for SK • That is, for any distinct tuples t1 and t2 in r(R), t1[SK] ≠ t2[SK] o Every relation has at least one default superkey: the set of all its attributes o Basically superkey is nothing but a key. It is a super set of keys where all possible keys are included (see example below). o An attribute or a set of attributes that can be used to identify a tuple (row) of data in a Relation (table) is a Superkey. • Candidate Key of R (all superkeys that can be candidate keys): o A "minimal" superkey o That is, a (candidate) key is a superkey K such that removal of any attribute from K results in a set of attributes that IS NOT a superkey (does not possess the superkey uniqueness property) (see example below). o A Candidate Key is a Superkey but not necessarily vice versa o Candidate Key: Are keys which can be a primary key.
    [Show full text]