資料庫管理 筆記 - 第七章 Databases in Applications

筆記說明

此筆記用途在於台北科技大學資訊與財金管理系大二上資料庫管理重點整理
並非所有人都適用，部分對我而言稍加容易的內容並不會寫在此內。

Client/Server Architecture 客戶端與伺服器架構

• 網路計算模型 Networked computing model
• 處理客戶端與伺服器行程(執行的程式) Processes distributed between clients and servers
• 客戶端
  使用服務的計算機
• 伺服器
  接受要求的計算機
• DBMS 只有資料庫的伺服器
• Internet 網路伺服器
• 圖解架構
  • 上層 GUI 介面
  • 中層 program , function
  • 下層 DBMS activities(運作)
  • 圖解

    

應用分區 APPLICATION PARTITIONING

• 將每一分 code 放到適合的地方去運作，適合的地方有客戶端 / 伺服器
• 優點
  • 性能提升 Improved performance
  • 互操作性改善 Improved interoperability
  • 平衡工作量 Balanced workloads

Fat and Thin Client

• Fat
  對於客戶端的電腦計算需求較大，DBMS 在客戶端
• Thin
  讓客戶端電腦只接受客戶需求，不在本地存取資料
• 圖解

  

網路應用程式要素 WEB APPLICATION COMPONENTS

• Database server
  需要一個 database Server，例如：Oracle, SQL Server, Informix, MS Access, MySql
• Web server
  接收與回應 http 要求，例如：apache
• Application server，例如：PHP
  透過程式碼編寫的動態網頁
• Web browser
  客戶可以透過網頁來瀏覽，例如：chrome、IE

MIDDLEWARE(中介軟體) AND APIS

• MIDDLEWARE
  允許應用程式去操作，而不需要用戶取理解程式碼或編寫。
• Application Program Interface (API)
  是一種應用程式，用來請求計算機執行程式或運算。
• Common database APIs –ODBC, ADO .NET, JDBC

透過中介軟體使用 API 的 6 部曲 STEPS FOR USING DATABASES VIA MIDDLEWARE APIS

• 建立或識別資料庫驅動程式
• 打開並連接資料庫
• 對資料庫執行查詢
• 處理查詢結果
• 必要，反覆執行前兩點
• 關閉資料庫連接

Python 應用資料庫管理

• Model Class
  創建數據、查詢數據
• Serialize Class
  轉換資料格式，如：data
• View Class
  讓使用者方便閱讀，如：browser

應用資料庫時的 3 個需要考慮因素

• 儲存
  • 放在 DBMS 的程式碼
  • 改善效能
• 請求與呼叫資料庫 Transactions
  • 涉及許多資料庫的更新
  • 有成功，才會執行成功，反之不執行
• 資料庫連接
  • 開放連接並長期使用時會占用 database 大量資源
  • 使用連接池
• 考慮這些因素時的優點
  • 編譯 SQL code 效能提升
  • 減少網路流量，而導致塞車的情況
  • 提高安全性
  • 加強資料完整性
  • Thinner clients
  • Scalability 可延伸性
  • Long-term cost reduction 降低長期成本
  • 要求方與回應方更好進行配對 Better match of systems to business needs
  • 改善客戶伺服器
  • 擁有競爭優勢 Competitive advantage
• 缺點
  • 寫程式要更多時間
  • 有些演算法不可移植，需要重寫

請求與呼叫完整性：ACID TRANSACTION INTEGRITY: ACID RULES

• Atomic
  • 請求與呼叫不可分割
  • Transaction cannot be subdivided
• Consistent
  • 請求前到請求後都沒有被改變
  • Constraints don’t change from before transaction to after transaction
• Isolated
  • 請求完成後用戶才會接收到資料
  • Database changes not revealed to users until after transaction has completed
• Durable
  • 資料庫的改動具有永久性
  • Database changes are permanent

要求合法訪問 CONTROLLING CONCURRENT ACCESS

• 問題
  在多用戶不斷發送要求給伺服器時，同時訪問會造成資料庫資料不一致。(lost update problem)
• 解決方法
  • 保持資料完整性、並確保不會因為交互操作而導致資料庫資料不一致
  • Serializability 可序列化
    變成 queue，一次一筆操作。請排隊
  • Locking Mechanisms 鎖定處理
    • 可序列化常用方法
      The most common way of achieving serialization
    • 在執行要求中，伺服器被鎖定
      Data that is retrieved for the purpose of updating is locked for the updater
    • 解鎖之前，其他用戶不可使用
      No other user can perform update until unlocked
    • 操作如下

      

• 問題範例，同時操作資料庫但資料庫資料不一致

  

LOCK LEVEL

• Database - used during database updates
• Table - used for bulk updates 區塊更新
• Block or page – very commonly used 非常常用
• Record - only requested row; fairly commonly used 經常會用
• Field –requires significant overhead; impractical
  字段，需要大量效能，不切實際。

Types of locks

• Shared lock
  • 唯讀，只能在讀取資料時使用
  • Read but no update permitted. Used when just reading to prevent another user from placing an exclusive lock on the record
• Exclusive lock
  • 不可以用來閱讀，只能在更新時使用
  • No access permitted. Used when preparing to update
• Dead Lock
  • 兩個以上的請求佔住公用資源，並都在等待對方解鎖資源時就會發生
  • An impasse that results when two or more transactions have locked common resources, and each waits for the other to unlock their resources
  • 圖解

    

MANAGING DEADLOCK

• Deadlock prevention 預防死鎖
  • 開始請求前，先將所有請求紀錄
  • 試圖更新（上傳）的資料的會被鎖住
  • 死鎖有成長期與收縮期
  • 可能沒辦法去判斷需要多少資源來解決死鎖
• Deadlock Resolution 死鎖原因
  • 一定是因為允許死鎖的發生，廢話，幹。但 PPT 真的這樣說..
  • 打破了防止死鎖的機制
  • 資源使用矩陣

VERSIONING 版本化

• 替代鎖定
• 假設不同版本不會同時更新
  Assumption is that simultaneous updates will be infrequent
• 每一筆請求都可以嘗試更新
  Each transaction can attempt an update as it wishes
• 系統會建立新版本，而不是不斷替換舊版本
  The system will create a new version of a record instead of replacing the old one
• 當請求衝突發生時，接收一個用戶的更新並通知另一用戶需要再次發送請求
  When a conflict occurs, accept one user’s update and inform the other user that its update needs to be tried again
• 發生請求衝突時，將造成請求衝突的請求回朔到發生請求之前
  Use of rollback and commit for this
• 圖解
  https://i.imgur.com/Wx9o930.jpg

DATA SECURITY

• 保護資料不被破壞或丟失
  Protection of the data against accidental or intentional loss, destruction, or misuse
• 由於可以透過網路訪問而讓 DATA SECURITY 增加難度
  Increased difficulty due to Internet access and client/server technologies

THREATS TO DATA SECURITY 威脅資料安全

威脅來自許多來源，資訊系統中的多個位置都存在漏洞
Threats come from many sources and vulnerabilities exist in multiple places within an information system

• 意外損失原因 Accidental losses attributable
  • 人為錯誤
  • 軟體故障 Software failure
  • 硬體故障 Hardware failure
• 盜竊和詐欺 Theft and fraud
• 失去隱密或機密性 Loss of privacy or confidentiality
  • Loss of privacy (personal data)
  • Loss of confidentiality (corporate data)公司資料
• 失去資料完整性 Loss of data integrity
• 無法使用資料 Loss of availability (e.g., through sabotage) 例如：破壞

CLIENT–SERVER APPLICATION SECURITY

• Static HTML files are easy to secure(安全)
  • Standard database access(訪問) controls
  • Place(放置) Web files in protected directories(目錄) on server
• Dynamic pages are harder
  • User authentication
  • Session security
  • SSL for encryption
  • Restrict(限制) number of users and open ports
  • Remove unnecessary programs

DATA PRIVACY(隱私)

• W3C Web Privacy Standard
  Platform for Privacy Protection (P3P)
• Addresses the following 需要解決的問題
  • Who collects data
  • What data is collected and for what purpose
  • Who is data shared with
  • Can users control access to their data 使用者可以去訪問資料
  • How are disputes resolved 如何解決紛爭
  • Policies(政策) for retaining(保留) data
  • Where are policies kept and how can they be accessed 哪裡可以查詢政策