Walia - Ch01 02 03 04(1)

Chapter 1

Who Needs a Database?

Walia - fall 2013 Chapter 1.1

Database Overview• A database is a set of related data.

• An old style library catalog, a rolodex or an address book are databases.

• Usually we use the term “database” to refer to electronic databases.


Data Versus Information• Related but distinct concept

• Data Information– Need to be processed, organized and structured

4

Graphical displays turn data into useful information that managers can use for decision making and

interpretation

Summarized data

Flat File Databases• The simplest electronic database structures are flat file structure.

• Flat file means that the data is stored in a single file.

• These files can be– Delimited– Fixed length– In a spreadsheet applicationWalia - fall 2013 Chapter 1.5

Delimited• In a delimited file each piece of data is separated from the others by a delimiter such as a comma or a semicolon.

• Delimited files are commonly used to transfer data from one data source to another.


Example: Comma Delimited File


8

Duplicate Data

Spreadsheets• Spreadsheets such as Microsoft’s Excel provide a more sophisticated form of flat file database.

• Spreadsheets often contain additional database tools to help sort and filter data.


Spreadsheet Example


Disadvantages of Flat File Databases

• Difficult to query and find information

• Data Redundancy-information is repeated and can be inconsistent

• Difficult to compare data across files


Database Management System

12

DBMS manages data resources like an operating system manages hardware resources

A software system that is used to create, maintain, and provide controlled access to user databases

Order Filing System

Invoicing System

Payroll System

DBMSCentral database

Contains employee,order, inventory,

pricing, and customer data

Elements of the Database Approach

• Data models – Graphical system capturing nature and relationship of data

– Enterprise Data Model–high-level entities and relationships for the organization

– Project Data Model–more detailed view, matching data structure in database or data warehouse

• Relational Databases– Database technology involving tables (relations) representing entities and primary/foreign keys representing relationships

• Use of Internet Technology– Networks and telecommunications, distributed databases, client-server, and 3-tier architectures

• Database Applications– Application programs used to perform database activities (create, read, update, and delete) for database users 13

Relational Databases• Relational Databases were designed to solve the problems with flat files and Hierarchical databases.

• The idea for relational databases was developed by Edgar F. Codd at IBM in 1970.

• He based the relational design on set theory and predicate logic.


Codd’s 12 Rules• Codd formulated the principles of relational databases in a document called “Codd’s 12 Rules.”

• There are actually 13 rules because they begin with 0.

• These rules can be found at http://en.wikipedia.org/wiki/Codd's_12_rules. Walia - fall 2013 Chapter 1.15

http://en.wikipedia.org/wiki/Codd's_12_rules

http://en.wikipedia.org/wiki/Codd's_12_rules

Nature of Relational Databases

• All data, even data about data such as a table and column names, are stored in tables.

• Each row in a table should have a column (or columns) that uniquely identifies it, a primary key.

• This primary key is repeated in other tables to create a relationship.

• When it is repeated it is known as a foreign key.


Related Tables

CustomerID(PK)

LastName

FirstName

Address City State

C41098X3 Carson Lewis 121 Center Street

Seattle WA

CV1099B1 Madison Sarah 1324 Broadway Seattle WAD345XU24 Brown Lisa 2201 Second Ave Seattle WA


TransactionID

TransactionType

TransactionDate

CustomerID(FK)

Amount

10002345 Deposit 2009-2-12 10:25:06

C41098X3 1245.76

10002346 Deposit 2009-2-12 10:27:13

CV1099B1 500.00

10002347 Withdrawel 2009-2-13-14:45:57

C41098X3 200.00

SQL• Codd said that a relational database should have a sublanguage that can manage all data manipulations as well as DBMS processes such as security and backup.

• SQL has become that language.


Example SQL Query


Table of Popular DBMSsRDBMS Comments URLORACLE The first commercial RDMS and the

biggest. Powers many of the world’s largest companies

http://www.Oracle.com

SQL Server Microsoft’s RDMS product. Ships in many versions designed for different company needs. Also powers many large enterprises

http://www.microsoft.com/sql/default.mspx

DB2 IBMs RDBMS http://www306.ibm.com/software/data/db2/9/

MySQL The most popular Open Source RDBMS currently owned by SUN

http://www.MySql.com

PostGres SQL Another free, Open source RDBMS. It is older and some would say more powerful than MySQL

http://www.postgresql.org/

ACCESS Microsoft’s Desktop Database http://office.microsoft.com/en-us/access/default.aspx?ofcresset=1


http://www.oracle.com/



http://www306.ibm.com/software/data/db2/9/

http://www306.ibm.com/software/data/db2/9/

http://www.mysql.com/

http://www.postgresql.org/

http://office.microsoft.com/en-us/access/default.aspx?ofcresset=1



Opportunities for Database Development

• Many small businesses and nonprofits have outgrown storing their data on paper or in spreadsheets.

• They have too much data to handle manually.

• They need to retrieve information quickly.

• They need to compare different pieces of information.


Chapter Two

Gathering Information

Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall Chapter2.22

Types of Database• There are several different functions a database can serve.

• Three of them are:– Transaction database– Management Information System– Business Intelligence.

Copyright © 2012 Pearson Education, Inc. Publishing as

Prentice HallChapter2.23

Transaction Databases• These are databases that are optimized to collect and process business transactions such as sales.

• They need to be fast and efficient.

• They often need to be available 24 hours a day, 7 days a week.



Information Management Systems

• Information management systems are optimized to process the transaction information, creating summaries and reports that are useful to business managers.

• They often work with a copy of the transaction data so as not to slow down the transaction database. Copyright © 2012 Pearson

Education, Inc. Publishing as Prentice Hall

Chapter2.25

Business Intelligence• Business Intelligence moves beyond management systems.

• It provides tools for “mining” data to look for patterns and trends that might help the business improve its offerings or service.



Identifying stakeholders

• One should first identify all the relevant stakeholders.

• A stakeholder is anyone who has a “stake” in the database project.

• This includes not only management, but anyone who will have to work with the database.

• It may also include customers.Copyright © 2012 Pearson


Chapter2.27

Interviews• Interviews are especially good for asking “open ended” questions.

• An open ended question is one that doesn’t have a set answer, such as “What is the aspect of the current database that gives you the most trouble?”

• It is important to make sure you interview all the stakeholders to get their perspectives, not just the management.



Chapter 3

Requirements and Business Rules


Client Server Relations• Much of software can be divided into one of two types:– Servers– Clients


Prentice Hall Chapter3.30

31

Client/Server Systems• The client–server model of computing is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called client

Servers• A server is software that offers “services” to other software.

• For instance a Web server provides Web pages that are requested by a browser.

• Databases usually behave as servers.

• (Some machines are optimized to host Server software. They are also commonly referred to as servers).



Clients• Clients are software that request services.

• A browser, for instance, requests a Web page to load and view.

• An application client can request data from a database.



Client Server Example



Review of the Issues• Reviewing the issues with the current data management system is a good place to start.

• Several of the requirements of the new database will be to resolve those issues.

• Reviewing the issues also helps you refocus on the “problem domain.”



Problem Domain• The problem domain represents the business problems a database is meant to solve.

• For a retail sale database, for instance, the problem domain is the sale, and all that is involved with the sale.

• For a science database dealing with earthquakes, the domain would be the locations, sizes and depths of earthquakes.


Prentice Hall Chapte3.36

Requirements• It is important to identify all the requirements of the database.

• A requirement represents something the database must store or do.

• There are several types of requirements:– Data Requirements– Report Requirements– Security requirements



Data Requirements• Data Requirements refer to the attributes the database must store in order to meet the information needs of an organization.

• It is important to identify these data requirements as completely as possible.



Report Requirements• Report requirements refer to the reports the database will have to generate.

• For example, the Tutor database will have to report on tutor’s hours, the numbers of unduplicated student sessions and the demographics of the students using the tutoring services, among others.

• The data required to generate those reports must be in the database.



Business Rules• A business rule is a rule about how data is collected, stored or processed.

• Examples of Business rules:– All quarter grades must be between 0 and 4.

– No patron can have more than 20 items checked out at a time.

– Payments must be made within 30 days or a 25 dollar late fee will be added.



Examples• Student may register for a course only if he/she has successfully completed the prerequisites for that course

• A new customer will get 10% discount for first three months

41

Sources of Business Rules

• Company managers• Policy makers• Department managers• Written documentation

– Procedures– Standards– Operations manuals

• Direct interviews with end users• Generally NOT Information System developers (most of the times)

Enforcing Business Rules

• Some business rules can be enforced in the database itself by placing constraints on the data. (The quarter grade must be between 0 and 4).

• Other business rules must be enforced through other means such as “Triggers.”



Triggers• A trigger is a block of SQL code that is triggered by an event such as an INSERT, UPDATE or DELETE.

• Triggers can be used to enforce things such as “No patron can check out more that 20 items.”

• When the database inserts a new item the trigger fires and totals the number of unreturned items. If it is greater than 20 it can notify the librarian or the patron.



Reviewing Requirements and Business Rules

• When you have listed all the requirements and business rules you can discover, you should always review them with the chief stakeholders.

• Use the review to make sure you have a complete list of requirements.

• Also make sure you have understood the business rules and processes.



Grouping Around Themes• The next step is to sort the nouns into broad themes or groups.

• These themes may become entities in your database design.

• The other nouns that belong to the those themes will become attributes.



Entities• Entities are things that the database is concerned with.

• In the tutoring database, for instance major themes are student, class, tutor, session and request.



Attributes• Attributes represent data that describe entities.

• Attributes of student, for instance, include:– Student ID– Student Name– Student Address– Student phone, etc.



Chapter 4

Database Design


Logical Design• Logical design is the entity design without regard to a Relational Database Management System.

• One of the principles of Relational databases is that the logical design should be the same regardless of the DBMS will be used.

• This means you don’t consider the particular limitations or features of a DBMS in the design.



Physical Design• Physical design is the logical design adapted to a particular DBMS.

• The design can change slightly to fit into the limitations of a DBMS or to take advantage of DBMS specific features.



The Importance of Data Models

• Data model – Relatively simple representation, usually graphical, of complex real-world data structures

– Communications tool to facilitate interaction among the designer, the applications programmer, business stakeholder, and the end user

• Good database design uses an appropriate data model as its foundation

E-R Model Constructs• Entities:

– Entity instance–person, place, object, event, concept (often corresponds to a row in a table)

– Entity Type–collection of entities (often corresponds to a table)

• Relationships:– Relationship instance–link between entities (corresponds to primary key-foreign key equivalencies in related tables)

– Relationship type–category of relationship…link between entity types

• Attribute– property or characteristic of an entity or relationship type (often corresponds to a field in a table)

53

Entity Relation Diagrams

• Entity Relation Diagrams are a common way of diagramming entities, their attributes and their relationships.

• An entity is represented as a rectangle divided into three parts:– The name of the entity– The primary key– The attributes Copyright © 2012 Pearson


Chapter4.54

An Entity



Attributes in bold are required.

EntityEntity – a class of persons, places, objects, events, or concepts about which we need to capture and store data.

– Named by a singular noun• Person: Employee, Student, Patient• Place: City, State, Country• Object: Machine, Building• Event: Sale, Registration• Concept: Account, Course

Slide 56

Data Modeling Concepts: Entity

8-57

Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier.

Places: sales region, building, room, branch office, campus.

Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle.

Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip.

Concepts: account, block of time, bond, course, fund, qualification, stock.

Attributes• Attribute–property or characteristic of an entity or relationship type

• Classifications of attributes:– Required versus Optional Attributes (Office Phone)

– Simple versus Composite Attribute (Employee_Address or Name)

– Single-Valued versus Multivalued Attribute (skills)

– Stored versus Derived Attributes (age or years_employed)

– Identifier Attributes (Flight_Number and Date)•Identifier (Key)–an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type 58

Relationships• A relationship between entities is established by repeating one field, usually the primary key field, from one table in a another table, usually as a foreign key.

• The primary key table is sometimes referred to as the “parent” table.

• Tables with the foreign keys are referred to as “child” tables.

• There are different ways of depicting relationships.



Arrow Headed Relationship

• Arrows are often used to depict relationships.

• The arrow’s head always points to the parent table, the primary key side of the relationship.



Crows Feet Notation for Relationships



The three lines, the crows foot, shows the “many” side of the relationship. The 0 on the building side says a building can have zero or many rooms, the line on the room side says a room must have a building.

Crows Feet Notation• Crows feet notation is an alternative to the arrow notation.

• It is more complex, but conveys much more information about the relationship itself.



Naming Conventions• Naming conventions are crucial for good design.

• Ideally you should have a consistent way of naming database objects such as tables, attributes, keys, and any other database objects such as stored procedures and triggers.



Book Naming Conventions• Entities and tables are named as single nouns like Tutor, Student, and Session.

• Attributes are named with the entity name followed by the attribute name.

• There are no underscores between. Each new word is capitalized: TutorLastName, StudentLastName, and so on. This can make for long attribute names, but it makes for maximum clarity.

• Primary keys end with the word “Key”: TutorKey, StudentKey, and so on.

• Foreign Keys retain the name of the primary key.



Term Equivalencies

Logical Design

Physical design

Theoretical

Entity Table Relation

Attribute Column, field Attribute

Row, Record Tuple



Repeating Fields• When creating an entity that can contain many of the same attributes it is tempting to list or number them.

• For example. a tutor can tutor many classes.

• The temptation is to create an entity like the following:



Relationships• Relationship

– Binds entities together– Relationship instance–link between entities (corresponds to primary key-foreign key equivalencies in related tables)

– Relationship type–category of relationship…link between entity types

– Relationships Can also Have Attributes

68

Relationships• There are three types of relationships between entities:– One to one– One to many– Many to many



Cardinality of Relationships• One-to-One

– Each entity in the relationship will have exactly one related entity

• One-to-Many– An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity

• Many-to-Many– Entities on both sides of the relationship can have many related entities on the other side

70

One to One• A one-to-one relationship means that for every one record in the primary key table there is no more that one related record in the foreign key table.

• Below are the crow’s feet notation for this relationship:



Zero or one

Exactly one

Notes on One-to-One Relationships

• One-to-one relationships are rare.

• They can be used to rid an entity of null (empty) attributes that inevitably result when contents of an entity have different attributes.

• They are sometimes used when data is split between entities for security reasons.



One-to-One Relationship to Prevent Nulls



Table Example: One to One For Reducing Nulls



One to One for Security Reasons



One to Many• One to many is the normal relationship between tables.

• It means that for every one record in the parent entity there can be zero to infinity records in the child entity.

• Here are the crows feet symbols for one-to-many relationships: Copyright © 2012 Pearson


Chapter4.76

One to zero or manyAt least one or many

One-to-Many Diagram



One Department can contain many Employees

Table Example of One to Many

DepartmentKey

DepartmentName

DepartmentPhone

DepartmentRoom

ACC Accounting (206)555-1234

SB201

IT Information Technology

(206)555-2468

NB100



EmployeeKey EmployeeLastName

EmployeeFirstName

DepartmentKey

FB2001D Collins Richard ITBN2004N Faulkner Leonore ITNC2004M Brown Carol ACCLL2006O Anderson Thomas IT

Caution: Cross Relationship Error



There is a temptation to think that because a department contains many employees, that the relationship should go both ways. Doing this however makes it impossible to enter data since before you enter a department there must be an existing employee in the Employee table, and before you enter an employee there must be an existing department in the Department table. The result is an unusable stalemate.

Many to Many• A many-to-many relationship means that each record in the primary entity can have many related records in a second entity and each record in the second entity can have many related records in the primary entity

• Many to Many relationships are legal in logical design, but no DBMS can implement them.

• Visio has no symbol for a many to many relationship, but it would be this:



Example of a Many-to-Many Entity Relationship



Resolving Many-to-Many Relationships

• Many-to-many relationships must be resolved into two one-to-many relationships.

• To do this it is necessary to create a linking between the two tables that have many-to-many relationships.



Many-to-Many Relationship Resolved



Table View: Magazine and Subscriber

MagazineKey MagazineName MagazinePriceTM2K1 Time 35.50NW2K1 Newsweek 36.40



SubscriberKey

Subscriber LastName

SubscriberFirstName

SubscriberAddress

SubscriberCity

Subscriber State

SubscriberPostalCode

4231 Johnson Leslie 101 Best Ave.

Seattle

WA 98007

4333 Anderson

Mark 1200 Western Blvd

Tacoma WA 98011

5344 Manning Tabitha 100 Westlake

Seattle

WA 98008

Linking Table: Subscription



SubscriptionKey

MagazineKey SubscriberKey

SubscriptionStartDate

1004 TM2K1 4333 1/15/20091005 NW2K1 4333 1/15/20091006 NW2K1 4231 2/1/20091007 TM2K1 5344 2/15/2009

Cardinality• Cardinality describes the number of permissible relationships between two entities.

• Maximum cardinality refers to the maximum number of permitted relationships. (For example, a customer can have no more than 4 listed emails.)

• Minimum cardinality refers the minimum number of permitted relationships. (For example, each customer must have at least one purchase in the purchase table.)



Types or Roles of Entities

• Entities can take on different roles.

• Below is a table of some common roles or types:



Entity Roles DescriptionDomain Entity describing a core business

element of the databaseLinking Entity used to resolve a many-to-many

relationship into two one-to-many relationships

Lookup Entity used to store lookup values and help ensure data integrity and consistency

Weak An entity that depends on another entity for its meaning

Example of a Weak Entity



An employee can have many dependents, so it is a good design practice to create a separate entity to describe dependents. However, the Dependent entity is a weak entity because it depends on Employee for its meaning

Documentation• Diagrams often communicate more clearly than words.

• It is important to keep all your entity diagrams for documentations along with notations about changes and versions.



Walia - fall 2013 90

Walia - Ch01 02 03 04(1)

Documents

Transcript of Walia - Ch01 02 03 04(1)