Database Logical Design

Transcription

1 Database Logical Design IT 5101 Introduction to Database Systems J.G. Zheng Fall 2011

2 Overview Relational model is a logical model Based on mathematical theories and rules Two ways to design a relational database model Through normalization Transforming conceptual models (ERD) 2

3 3 Level Database Design Creating an ER diagram and associated data dictionary Conceptual Design Transforming ERD to relational model: tables, keys (constraints), etc. Logical Design Creating the database and other supporting structures based on a specific DBMS Physical Design 3

4 Transform ER to Relations Steps 1. Transform basic entities, identifiers and attributes a) Create tables, columns and keys b) Define data type, length, and other constraints for each column 2. Transform relationships by determining foreign keys a) Which column is foreign key? Which table to have the foreign key? Should a third table be added? b) Is the value of the foreign key required? c) Define referential integrity actions 4

5 Database Structure Representation Text style [Table Name]([Primary Key], attribute, [Foreign Key], attribute, ) FK: [Foreign Key] --> [Reference Table].[Primary Key] FK: (if more than one foreign key) Example Primary Key(s): underscored Department (DeptID, DeptName, Location) Employee (EmpID, EmpName, Department) FK: Department Department.DeptID Foreign Key: definition Foreign Key: italicized 5

6 1. Design Tables and Columns Each entity becomes a relation (table) Attributes of the entity become fields of that table Identifier becomes primary key 6

7 Column Definition Column name Data type: generic data types Character, numeric, date/time, boolean/bit Column length (size) More requirements: constraints Required or not Uniqueness Domain values, range Default values 7

8 Data Type Data types Character: string/text, fixed vs. varied length Numeric: integer, float/decimal Date/Time: for date and time related attributes Boolean/bit: for attributes which only have two values Note: use numeric data type only when involving calculations The following attributes are usually designed as character types, but not number types: ZIP code SSN Phone number 8

9 Derived Attribute Derived attribute An attribute that is generated based on other columns, or rows GPA, TotalPayment, Age, etc. Derived attributes are usually not modeled at this time 9

10 2. Transform Relationships Relationships are defined by foreign key constraints One foreign key only dereferences one unique key in one other table (one key one table) Design foreign key constraint The whole purpose is to avoid null values Which column (in which table) is the foreign key? When no existing attribute can be a foreign key, we need to add one to match the PK in its referencing table. Which table should it be added to? 10

11 FK in 1:1 Relationships Generally, a foreign key can be in either table (choose the one that makes more business sense) Further design of the foreign key needs to consider minimum cardinalities Example: One-to-one relationship between employee and locker Lockers Employees LockerNumber Size Location Assigned to / Have Foreign Key? EmployeeId FirstName LastName Gender Design: Employees (EmployeeId, FirstName, LastName, Gender) Lockers (LockerNumber, Size, Location, AssginedTo) FK: AssignedTo Employees.EmployeeId We also usually design the FK in 1:1 relationship to be a candidate key (unique constraints) This attribute is added to match the PK in the Employees table. 11

12 FK in 1:N Relationships The primary key from the One side is placed in the Many side as a foreign key Example Course CourseNumber Title Department Description Taught by / Teach Instructor InstructorId FirstName LastName Rank Design Instructor (InstructorId, FirstName, LastName, Rank) Course (CourseNumber, Title, Department, Description, TaughtBy) FK: TaughtBy Instructor.InstructorId Course is on the many side, which receives the foreign key. This foreign key is added to course; if the course has a instructor attribute already, then simply make the attribute as a foreign key no need to add another one. 12

13 Why is FK on the many side? The foreign key is always on the Many side to avoid redundancy InstructorId FirstName LastName CourseNumber gzheng1 Jack Zheng gzheng1 Jack Zheng gzheng1 Jack Zheng CourseNumber Title Taught By CIS 2010 Intro CIS gzheng CIS 3730 Database gzheng CIS 3300 Analysis vvaish2 Placing the FK CourseNumber on the One side (Instructor) causes redundancy. Redundancy From a normalization perspective, there is a partial dependency: (InstructorId, CourseNumber) is a composite key, but InstructorId determines FirstName and LastName. Placing the FK TaughtBy on the Many side (Course) minimizes redundancy. 13

14 FK in N:M Relationships Many-to-Many There is no direct way to map many-to-many relationships in relational databases A Many-to-Many relationship should be converted to two One-to-Many relationships An intersection entity, with two one-to-many relationships is created. The identifier is the combination of the two identifiers from the two original entities. Orders OrderNumber OrderDate OrderBy Orders OrderNumber OrderDate OrderBy Has / Is in Has / Is in OrderLineItem OrderId ProductId Has / Is in Products ProductId ProductName Specification UnitPrice Products ProductId ProductName Specification UnitPrice The many side now points to the new entity; the one side points to the original entity. 14

15 Text Style of the Design Orders (OrderNumber, OrderDate, OrderBy) Products (ProductId, ProductName, UnitPrice) OrderLineItem (OrderNumber, ProductId, Quantity) FK: OrderNumber Orders.OrderNumber FK: ProductId Products.ProductId This is the new intersection table: FKs on the many side. 15

16 Visio Model of the Design The primary key is a composite key consisting of both primary keys from other two tables If there are more attributes for the relationship, add them to the intersection table as columns OrderLineItem PK,FK1 OrderNumber CHAR(10) PK,FK2 ProductId CHAR(10) u:c d:c Foreign keys are added to the intersection table referencing corresponding tables Quantity TEXT(50) u:c d:c The reference line arrow points to the primary key table Orders PK OrderNumber CHAR(10) OrderDate DATETIME OrderBy CHAR(10) Products PK ProductId CHAR(10) ProductName TEXT(30) UnitPrice DOUBLE Referential integrity: actions 16

17 Surrogate Key Surrogate keys can be defined at this stage It s common to add a surrogate key to replace the composite key in intersection tables Example A surrogate key is added OrderLineItem (LineItemNumber, OrderNumber, ProductId, Quantity) FK: OrderNumber Orders.OrderNumber FK: ProductId Products.ProductId Also Use surrogate key when a composite primary key will be used as a foreign key This is much simpler 17

18 Setting FK Nullability Is the foreign key s value required? Check the minimum cardinality on the primary key table (parent table) side Optional Set foreign key Optional or Null Mandatory Set foreign key Required or Not Null FK setting in Visio Check required see slide 15, both minimum cardinalities are mandatory. Also see the Visio tutorial. 18

19 Creating Logical Models Steps Summary 1. Created tables and columns Define table name Define columns: name, data type, length, and Required constraint Define primary key 2. Create foreign keys Determine foreign keys and referencing tables Defining FK required setting: NULL (optional) or NOT NULL (required) Define referential integrity actions 19

20 Summary Key concepts Relational model Referential actions (all 5) Null Key skills Transform ERD to relational models Tables, primary keys, data types, and other column constrains Foreign key, referential actions, and other constraints Know how to trans form three types of relationships (1:1, 1;N, N:M) Understand and use the text style of database structure representation Understand Visio database model diagrams Use Visio database model diagram to design logical relational models 20