Chapter 3 Database Modeling Building Blocks 1 Ch

Chapter 3 Database Modeling Building Blocks 1

Ch 3: Database Modeling Building Blocks In this chapter, you learn about the following: ❑ Information, data, and data integrity ❑ Tables ❑ Fields, columns, and attributes ❑ Rows, records, and tuples ❑ Datatypes ❑ Validation and NULL values ❑ Relations, relationships, and some normalization ❑ Entity Relationship Diagrams (ERDs) ❑ Primary and foreign keys ❑ Referential integrity ❑ Indexes ❑ Specialized objects (views and materialized views) 2

Ch 3: Database Modeling Building Blocks Information, Data and Data Integrity ü In computer jargon, information is data that is stored in a database, processed by programs ü The concept of data: Data is composed of unique, specifically formatted items of information. ü The concept of a computer program: Programs are sets of precise instructions, used to manipulate and process changes to a database. ü The concept of a datatype: Datatypes comprise the forms data can take, such as numbers, dates, strings, and others. ü The concept of data integrity: The integrity of data is the validity of data 3

Ch 3: Database Modeling Building Blocks Understanding the Basics of Tables üTable fields express the metadata (horizontal) dimension üTables records duplicate the set of fields into data (vertical) dimension All records in the same table have the same table structured applied to them 4

Ch 3: Database Modeling Building Blocks Understanding the Basics of Tables contain fields and records. Fields apply structure to records, whereas records duplicate field structure an indefinite number of times. 5

Ch 3: Database Modeling Building Blocks Records, Rows, and Tuples The terms record, row, and tuple all mean the same thing. They are terms used to describe a record in a table. 6

Ch 3: Database Modeling Building Blocks Fields, Columns and Attributes q The terms field, column, and attribute all mean the same thing. They are all terms used to describe a q field in a table. A field applies structure and definition to a chunk of data within each repeated record. q Whereas fields apply structure to records, datatypes apply structure and restrictions to fields and values in those fields. The International Standard Book Number (ISBN) uniquely identifies a book on an international basis 7

Ch 3: Database Modeling Building Blocks Datatypes can be divided into three separate sections: ❑ Simple datatypes: These are datatypes applying a pattern or value limitation on a single value such as a number. ❑ Complex datatypes: These include any datatypes bridging the gap between object and relational databases, including items such as binary objects and collection arrays. ❑ Specialized datatypes: These are present in more advanced relational databases catering to inherently structured data such as XML documents, spatial data, multimedia objects and even dynamically definable datatypes. 8

Ch 3: Database Modeling Building Blocks Strings: ❑ Fixed-length strings Simple Datatypes ❑ Variable-length strings 9

Ch 3: Database Modeling Building Blocks Numbers: ❑ Integers Simple Datatypes ❑ Fixed-length decimals 10

Ch 3: Database Modeling Building Blocks Numbers: ❑ Floating points: Simple Datatypes For most databases, any INSERT commands into the float fields exceeding length requirements (such as 32 bytes for SFLT) will not produce errors 11

Ch 3: Database Modeling Building Blocks Date and times: ❑ Floating points: Simple Datatypes A timestamp datatype displays both date and time information regardless of any default date formatting executing in the database 12

Ch 3: Database Modeling Building Blocks Complex Datatypes some complex datatypes: ❑ Binary objects ü A large object such as a graphic is so very much larger than the length of an average table record ü A typical record in a table may occupy at most 2 KB ü Binary objects were created to physically separate binary values from traditional table record values ❑ Reference pointers ü a reference pointer is a variable containing an address on disk or in memory ü A pointer provides the advantage of not having to specify how many bytes the pointer value occupies ü pointer points to an object or file stored externally to the database, pointing from a field within a table, to the object stored outside the database 13

Ch 3: Database Modeling Building Blocks Complex Datatypes some complex datatypes: ❑ Collection arrays ü A collection is a set of values repeated structurally (values are not necessarily the ü same) ü Collection arrays can have storage structures defined in alternative locations to table fields as for binary objects ü Collection arrays, much like program arrays, can be either fixed length or dynamic ❑ User-defined types ü A user-defined type allows the creation of new types. ü Creation of a new type means that user-defined datatypes can be created by programmers, even using other user-defined types ü fields can be created in tables where those fields have user-defined datatypes 14

Ch 3: Database Modeling Building Blocks Constraints and Validation Relational databases allow constraints, which restrict values that are allowed to be stored in table fields. Some examples of constraints q. NOT NULL q. Validation check: a validation checking type of constraint restricts values in fields when a record is added or changed in a table. q. Keys—Key constraints include primary keys, foreign keys, and unique keys. 15

Ch 3: Database Modeling Building Blocks Understanding Relations for Normalization What Normalization means? q By dictionary definition, the term normalization means to introduce consistency with respect to style and content q In terms of relational database modeling, that consistency becomes a process of removing duplication in data q Commercially speaking, primary objectives are usually to save space and organize data for usability and manageability, without sacrificing performance q Normalization is an incremental process. In other words, each Normal Form layer adds to whatever Normal Forms have already been applied 16

Ch 3: Database Modeling Building Blocks Understanding Relations for Normalization Benefits of Normalization Effectively minimizing redundancy is another way of describing removal of duplication. The effect of removing duplication is as follows: ❑ Physical space needed to store data is reduced. ❑ Data becomes better organized. ❑ Normalization allows changes to small amounts of data (namely single records) to be made to one table at once. 17

Ch 3: Database Modeling Building Blocks Understanding Relations for Normalization Potential Normalization Hazards Some detailed aspects of the positive effects of normalization mentioned previously can have negative side effects Keep the following in mind: Ø Physical space is not nearly as big a concern as it used to be Ø Too much minimization of redundancy implies too much granularity and too many tables. Too many tables can lead to extremely huge SQL join queries. Ø Better organization of data with extreme amounts of redundancy minimization can actually result in more complexity 18

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Definition (ERD) The different types of inter-table relationships that can be formed between different tables can be best described as displayed in Entity Relationship Diagrams (ERDs). 19

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD ü A crow’s foot is used to describe the “many” side of a one-to-many or manyto-many relationship ü you should get the idea that many toes implies more than one and thus many, regardless of how many toes a crow actually has 20

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD One-to-One ü One-to-one relationships are often created to remove frequently NULL valued fields from a table ü SQL code with more tables in joins can cause serious performance issues there is exactly one record in the EDITION table for every record in the RANK table, and visa versa. 21

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD One-to-Many One-to-many implies one entry to many entries between two tables 22

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Many-to-Many v A many-to-many relationship means that for every one record in one table there are many possible records in another related table, and visa versa (for both tables) v The classic example of a manyto-many relationship is many students enrolled in many courses at a university v a uniquely identifying table is required if unique items are needed by end-users or an application. 23

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Zero, One, or Many Relationships between tables can be zero, one, or many. Zero implies that the record does not have to exist in the target table; one with zero implies that it can exist; one without zero implies that it must exist; and many simply implies many. 24

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Identifying and Non-Identifying Relationships ❑ Identifying relationship—The child table is partially identified by the parent table, and partially dependent on the parent table. The parent table primary key is included in the primary key of the child table. ❑ Non-identifying relationship—The child table is not dependent on the parent table such that the child table includes the parent table primary key as a foreign key, but not as part of the child table’s primary key. 25

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Identifying and Non-Identifying Relationships ❑ A dependent table exists for a table with an identifying relationship to a parent table. ❑ Non-dependent entity or table— This is the opposite of a dependent table. 26

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Understanding Keys Ø An index in a relational database is a copy of a part of a table Ø An index can be created on any field in a table Ø A key is also an index Ø A key is a term used to describe the fields in tables linking tables together to form relationships Ø A key is an index because it copies fields in a table into a more efficient searching structure Ø There are three types of keys: a primary key, a unique key, and a foreign key 27

Ch 3: Database Modeling Building Blocks Primary Keys Representing Relationships in an ERD ü A primary key is used to uniquely identify a record in a table ü Integers are used as primary keys ü Primary keys are known as surrogate keys because they substitute as primary keys for names ü A primary key is also used to define relationships between tables

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Unique Keys ü A unique key is created on a field containing only unique values throughout an entire table ü A unique key ensures uniqueness across a table ü Unique keys are not used to define relationships between tables CREATE TABLE Author ( author_id INTEGER NOT NULL, name VARCHAR(32) NULL, CONSTRAINT XPK_Author PRIMARY KEY (author_id), CONSTRAINT XUK_A_Name UNIQUE (name) ); 29

Ch 3: Database Modeling Building Blocks Foreign Keys Representing Relationships in an ERD ü Foreign keys are the copies of primary keys created into child tables to form the opposite side of the link in an inter-table relationship ü In the figure, each record in the PUBLICATION table has a copy of the parent table’s AUTHOR_ID field value ü In the Figure, the COAUTHOR table has a primary key made up of two fields 30

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Exercise Creating Some Simple Tables The figure shows some data Do the following exercise: 1. Create two related tables linked by a oneto-many relationship 2. Assign a primary key field in each table 3. Assign a foreign key field in one table. 31

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD How It Works Ø Typically, different bands or musical groups create many Tracks Ø Band names are the only duplicated values, so they make up the table on the parent side of the one-tomany relationship Ø You may have three options as in the figure 32

Ch 3: Database Modeling Building Blocks Representing Relationships in an ERD Understanding Referential Integrity A. There are circumstances to consider in terms of how Referential Integrity is generally enforced B. When adding a new record to a child table, if a foreign key value is entered, it must exist in the related primary key field of the parent table C. When changing a record in a parent table if the primary key is changed, the change must be cascaded to all foreign key valued records in any related child tables D. When changing a record in a child table, a change to a foreign key requires that a related primary key must be checked for existence E. When deleting a parent table record then related foreign key records in child tables must either be cascade deleted or deleted from child tables first 33

Ch 3: Database Modeling Building Blocks Understanding Indexes What Is an Index? q An index is usually and preferably a copy of a very small section of table q All relational databases have some type of SQL execution optimization process q Optimizer decides whether to access the table alone, or if it is faster to read the index q An index essentially behaves like the table of contents at the front of a Book Following are some things to be avoided when indexing: 1. Creating too many indexes—Too many indexes on a table can result in very slow database change responses. 2. Indexing too many fields—An index must be relatively much smaller than a table 34

Ch 3: Database Modeling Building Blocks Understanding Indexes What Is an Index? q An index is usually and preferably a copy of a very small section of table q All relational databases have some type of SQL execution optimization process q Optimizer decides whether to access the table alone, or if it is faster to read the index q An index essentially behaves like the table of contents at the front of a Book Following are some things to be avoided when indexing: 1. Creating too many indexes—Too many indexes on a table can result in very slow database change responses. 2. Indexing too many fields—An index must be relatively much smaller than a table 35

Ch 3: Database Modeling Building Blocks Understanding Indexes Types of Indexes q BTree index ü A BTree index looks like an upside down tree ü The tree is called “binary” because binary implies two options under each branch node: branch left and branch right. ü The binary counting system of numbers contains two digits, namely 0 and 1 ü a BTree consists of a root node, branch nodes, and ultimately leaf nodes containing the indexed field values in the ending (or leaf) nodes of the tree. 36

Ch 3: Database Modeling Building Blocks Understanding Indexes Types of Indexes q Bitmap index ü A Bitmap index contains binary representations for each record using 0’s and 1’s. ü Values cannot be slotted into the existing Bitmap index structure as readily as can be ü done when updating a BTree index 37

Ch 3: Database Modeling Building Blocks Types of Indexes Understanding Indexes q ISAM index ü Indexed Sequential Access Method (ISAM) uses a simple structure with a list of record numbers ü ISAM indexes are best used for static data q Hash table ü A hash table is a copy of data but rearranged into a different and more efficiently accessed order depending on a hashing algorithm ü For example, a hashing algorithm takes a string and creates a number from that string ü Hash indexes can be highly efficient for read access, but are best avoided when subjected to any kind of data changes Index Organized Table ü An Index Organized Table (IOT) builds a table in the sorted order of an index, typically using a BTree index ü index record length is much longer than normal because index leaf blocks 38 contain all fields in the entire record length of a table

Ch 3: Database Modeling Building Blocks Understanding Indexes Different Ways to Build Indexes ü Ascending or descending index—An index can be built sorted in a normally ascending order (such as A, B, C) or in descending order (such as C, B, A) ü Unique index— Indexes values must be unique (can’t contain duplicate values) ü Non-unique index—Non-unique indexes contain duplicated or repeated values in the index 39

Ch 3: Database Modeling Building Blocks Understanding Indexes Different Ways to Build Indexes ü Composite index—Indexes can be built on more than a single field and are known as composite field indexes ü Compressed indexes—Some databases allow compression of composite indexes where repeated prefix values are effectively indexed within the index ü Reverse key indexes—Only a very select few databases allow building of indexes such that indexed field values are stored as reverse strings 40

Ch 3: Database Modeling Building Blocks Summary In this chapter, you learned about: ❑ Building tables containing fields, datatypes, and simple validation ❑ The different types of relationships between tables ❑ Representing relations in ERDs ❑ Defining referential integrity relationships between tables using primary and foreign keys ❑ The types and uses of indexes 41

Ch 3: Database Modeling Building Blocks Exercises 1. Write two CREATE TABLE commands for the tables in Option 3 of Figure 3 -24. Make sure that all primary key, foreign key, and any potentially necessary nique keys are included. 2. Write CREATE INDEX commands to create all indexes on any foreign keys indicated in the CREATE TABLE command written for the previous question. 42