Top Banner
CSE 136 Lecture 2 Database design steps for the enterprise Logical Design Overview Physical Design Logical design in detail Conceptual Modeling Model to Schema Database Security Enterprise Database Environment Continuous Integration DB – build DB project
41
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Day2

CSE 136 Lecture 2

Database design steps for the enterprise Logical Design Overview Physical Design Logical design in detail

Conceptual Modeling Model to Schema

Database Security Enterprise Database Environment Continuous Integration DB – build DB

project

Page 2: Day2

Database Design Step

Determine requirements

RequirementAnalysis

Logical Design

Physical Design

Implementation

Model Integrated views

Transform to SQL tablesIf there aremultiple dbdesigners

Normalize

normalize until ithurts

select indexes

Implementation

de-normalize untilit works

De-normalize

Monitor and detect changing requirements

ER Model

Using MS SQL 2008

Page 3: Day2

Logical Design Overview 1

Conceptual data modeling

The data requirements are analyzed and modeled using an ER orUML diagram that includes, for example, semantics for optionalrelationships, ternary relationships, supertypes, and subtypes(categories).

Outcome ofyour analysis

UML diagram

customer orders product

customer served-by salesperson

product sold-by salesperson

Page 4: Day2

Logical Design Overview 2

View Integration

Usually, when the design is large and more than oneperson is involved in requirements analysis, multipleviews of data and relationships result

Multiple Views,but one final

design

Page 5: Day2

Logical Design Overview 3

Tranformation (model to SQL tables)

Based on a categorization of data modeling constructs and a set ofmapping rules, each relationship and its associated entities aretransformed into a set ofDBMS- specific candidate relational tables

Data Definition Language(DDL)

More details later

Page 6: Day2

Logical Design Overview 4

Normalization

Functional dependencies (FDs) are derived from theconceptual data model diagram and the semantics ofdata relationships in the requirements analysis.

job-level 10employees are

allowed 30 days ofvacation days per

year

10 3010

EntityRelationships

Page 7: Day2

Physical Design

Physical Design

involves the selection of indexes (access methods),partitioning, and clustering of data

Indexing

performance

index is based on binary-tree

Clustering

fail-over for reliability

Partitioning

different disks for performance

Materialized viewers

caching remote data

Denormalization

faster retrieval - combine normalized tables into larger tables

Page 8: Day2

Conceptual Modeling - generalization

If there is a generalization hierarchy among entities, then put theidentifier and generic descriptors in the super-type entity and putthe same identifier and specific descriptors in the subtype entities

grad undergrad international professional

phd/ma/ms 1st, 2nd.. nationality company

Page 9: Day2

Conceptual Modeling - relationships connectivity

The connectivity of a relationship describes a constraint on theconnection of the associated entity occurrences in the relationship

1 manager

many employees

Isaac C.Doug N.Tim L.Trevor S.

IRADmilitarymaps

Existence of an entity occurrence in a relationship is defined as eithermandatory or optional

dept is optional

Office is required

Page 10: Day2

Model to SQL schema

Data Definition Language Why use data definition language?

Multiple database designers modifying DDL Version Control Build the database script from scratch (for unit

testing) Examples

Create table Alter table Drop table Create/drop view

Page 11: Day2

Model to SQL 1

One-to-one, both entities mandatory

1-to-1relationship

Deleting a report also deletes abbreviationentry with the same report_no

update report.report_no will also updatethe abbreviation.report_no

Page 12: Day2

Model to SQL 2

Many-to-many, both entities optional

combination keys

Page 13: Day2

Enrollment example

Step 1. CreateStudent table

Student

student_idfirst_namelast_name

etc

"A0123456789""Becky""Smith"

Step 2. CreateCourse table

Course

course_idcourse_number

course_titledepartment_id

100001"CSE 132A"

"Database Systems I"20001

Step 3. CreateCourse_ScheduleTable

Course_Schedule

schedule_idquarter

yearcourse_id

section_number

course_id

200015"fall"2011

100001"A00"

Step 4. CreateEnrollment table

Enrollment

student_idschedule_id

"A0123456789"200015

student_id

schedule_id

Enrollment table contains all the students enrollment

Commonly known as a join-table (combo-key; many-to-many)

Page 14: Day2

Enrollment example

Student

student_idfirst_namelast_name

etc

Course

course_idcourse_number

course_titledepartment_id

Course_Schedule

schedule_idquarter

yearcourse_id

section_number

Enrollment

student_idschedule_id

student_id

course_id

schedule_id

Which table should "grade" column be added?

grade

Which table should "instructor" column be added to?

Instructor_id

Instructor

instructor_idfirst_namelast_name

titledegree

instructor_id

What about pre-requisites?

prereq_course_id

How about 100,both 140 & 141 are

pre-req for 136?

Pre_ req

course_idprereq_course_id

course_idcourse_id

---- -----136 100136 140136 141

Page 15: Day2

SQL Security

Secure Configuration Authentication

login/password Authorization

What you can access after you login

Data Encryption Protecting sensitive

data from internal and external hackers

Page 16: Day2

SQL Security - Secure Configuration

Physically secure the server behind firewall Enable only the minimum network protocols

required Use Windows Update to apply patches Surface Area Configuration - turn off default

SQL features CLR Integration Database mirroring Debugging Service broker E-Mail functions

Page 17: Day2

SQL Security - Authentication Use simple connection strings containing user names

and passwords during development Create SQL user for test-user (shows password in web.config &

app.config) Use windows authentication in production with more

security SQL 2008 uses encryption of the channel by default

(avoid data sniffing) Windows Group Policy

password complexity password history password age expiration lockout after failed attempts

Page 18: Day2

SQL Security - Authorization

After authentication, what can you access?

Depends on your roles (owner, admin, operator, reader, etc)

Principal Any individual, group, or process that can

request access to a protected resource Securable

object that you can secured by granting or denying of permissions

Page 19: Day2

SQL Security - Principal

Windows-level principals Domain, local, group

SQL Server-level principals SQL login login mapped to a windows login login mapped to a certificate login mapped to a asymmetric key

Database-level principals Database user user mapped to SQL server login user mapped to windows login, certificate, asymmetric key Database role Application role etc...

Page 20: Day2

SQL Security - Securables

Server

DatabaseEndpointRemote BindingRouteLogin

Database

Application RoleAssemblyAsymmetric KeyCertificateDatabase userFixed Database RoleFull-text catalogMessage typeServiceService ContractSymmetric Key

Schema

DefaultFunctionProcedureStatsQueueRuleSynonymTableTriggerTypeViewXML Schema

Assigning or refusing permissions on a securable object to a principal

GRANT DENY

REVOKE - remove previously assigned permission (grant or deny)

Creating database with security in mind requires detail analysis

Page 21: Day2

SQL Security – Dynamical SQL Execute(@sql)

@sql is a dynamically generate SQL statement @sql = ‘select * from course where name = ‘’‘ + @search + ‘’’’

Open for SQL injection attack @search = ‘cse’’’; delete from users‘

Use sp_executesql (@sql, @search_text)

Page 22: Day2

SQL Security – Encryption

Built-in SQL encryption methods: EncryptByPassPhrase(),

DecryptByPassPhrase() EncryptByCertificate(),

DecryptByCertificate() Encryption side-effects:

Storage (encrypted values are larger size) Performance

Create Index on encrypted data Create Index on hash value

Page 23: Day2

Review question

Difference between db logic design and physical design?

Difference between deny vs revoke? Can you think of a generalization scenario for

your project? How many entities will you have in your db

design? Can you identify where you would need indexes

in your db? What db objects would you want to provide

more security in your db design?

Page 24: Day2

Break time

Page 25: Day2

Enterprise DB – availability & load

Availability = (Total Units of Time – Downtime) / Total Units of Time 8,760 hours (365 days 24 hours) in a calendar

year 100 hours of downtime during the year (8760 – 100) / 8,760 (98.9% uptime)

Fail-over When one db fails, another becomes active

DB Load Balance Distribute data across different servers (multiple

active databases)

Page 26: Day2

Enterprise DB - architecture

Clustering Log shipping Mirroring Snapshot replication Merge replication Peer-to-peer replication (transactional) Combinations

Cluster & mirror Cluster & log-shipping Cluster & replication

Page 27: Day2

Enterprise DB - clustering

client 1

client 2

client 3

One IP address forall clients

Node 1 Node 2 Node 3

Private Network Private Network

Node - SQLServer

ClusteredInstance

Shared Storage

Internally replicated files in the SAN(storage area network) box

Page 28: Day2

Enterprise DB - log shipping

Primary

Back uptransaction

log

Copy transactionlog (FTP?)

Secondary

Restoretransaction

log

Page 29: Day2

Enterprise DB - mirroring

Principal

1. write transaction to log

2. Transmit transaction

Mirror

3. write transaction to log

4. acknowledgement

5. Commit data 6. Commit data

Witness

Page 30: Day2

Enterprise DB – snapshot replication

Publisher

Snapshot agentDistribution agent

Distributor Subscriber

CreateSnapshot

snapshot folder

Apply snapshot

Page 31: Day2

Enterprise DB – merge replication

ClientsClients

Distributor

Merge Agent

Page 32: Day2

Enterprise DB – peer-to-peer

China

U.S.

Spain

Setup in softwareconfiguration

Each databasehas its owndistributor

Page 33: Day2

DB Architecture comparison

Distance

Serverswitch

Downtimeduring switch

Data Lossduring switch

Single pointof failure

# of fail-overservers

Schemadependency

LoadBalance

Limited None None None

Automatic AutomaticManual Manual

Seconds SecondsMinutes Minutes

No RarelyLikely Likely

Disk None NoneNone

up to 16 1Unlimited Unlimited

No NoNo Yes

Yes NoNo Yes

Page 34: Day2

Enterprise DB – cluster & mirror

Mirror

No Witness Server

Page 35: Day2

Enterprise DB – cluster & log-shipping

SQL Cluster

Copy transaction log

Secondary

Restoretransaction

log

Page 36: Day2

Enterprise DB – cluster & replication

SQL Cluster with replication and a remote distributor

Remote Distributor

Subscriber

Page 37: Day2

DB for Continuous Integration Database needs to be built locally

For individual C# developers coding locally For running unit tests locally Database code needs to be in the source

control (version control) Nightly builds on the server

Solution: Database Solution in VS 2010 (cse 136) Database build script (*.sql) Command shell (CreateDB.cmd)

Page 38: Day2

Review question

Difference between fail-over and load balance?

What are the pros and cons of clustering?

What scenario would you recommend logging shipping instead of mirroring?

What scenario would you recommend mirroring instead of replication?

Page 39: Day2

Demo

SQL Mixed mode Create SQL user Show Day 2 tutorial Run .cmd to generate db

Page 40: Day2

Assignment

Due Day 4 Create a database in SQL 2008 Create a database diagram Create SQL Stored Procedures based on

your activity diagram(s) for your entire project’s features.

Create a database solution using VS 2010 (see day 2 tutorial)

Run the db command script

Page 41: Day2

References

Database Modeling and Design Pro SQL Server 2008 Failover Clustering