SA Chapter 10


Published on

SA Chapter 10

Published in: Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SA Chapter 10

  1. 1. Phase 3: System Design- Data Design บทที่ 10
  2. 2. Purpose of Database Design (1) <ul><li>Structure the data in stable structures, called normalized tables </li></ul><ul><ul><li>Not likely to change over time </li></ul></ul><ul><ul><li>Minimal redundancy </li></ul></ul><ul><li>Develop a logical database design that reflects actual data requirements </li></ul><ul><li>Develop a logical database design from which a physical database design can be developed </li></ul>
  3. 3. Purpose of Database Design (2) <ul><li>Translate a relational database model into a technical file and database design that balances several performance factors </li></ul><ul><li>Choose data storage technologies that will efficiently, accurately and securely process database activities </li></ul>
  4. 4. Data Modeling แสดงรายละเอียดของข้อมูลในส่วนของ definition, structure และ relationships ซึ่งไม่สามารถแสดงใน Data flow diagrams และ processing logic techniques ที่เรียนไปแล้วในบทก่อน Data Modeling Data modeling มี 3 ระดับได้แก่ conceptual data model, logical data model และ physical file and database.
  5. 5. Conceptual Data Modeling <ul><li>Representation of organizational data </li></ul><ul><li>Purpose is to show rules about the meaning and interrelationships among data </li></ul><ul><li>Entity-Relationship (E-R) diagrams are commonly used to show how data are organized </li></ul><ul><li>Main goal of conceptual data modeling is to create accurate E-R diagrams </li></ul><ul><li>Methods such as interviewing, questionnaires and JAD are used to collect information </li></ul><ul><li>Consistency must be maintained between process flow, decision logic and data modeling descriptions </li></ul>
  6. 6. Process of Conceptual Data Model <ul><li>First step is to develop a data model for the system being replaced </li></ul><ul><li>Next, a new conceptual data model is built that includes all the requirements of the new system </li></ul><ul><li>In the design stage, the conceptual data model is translated into a physical design </li></ul>
  7. 7. Sample conceptual data model diagram
  8. 8. Conceptual Data Model <ul><li>First Deliverables outcome is the entity-relationship diagram which ….. </li></ul><ul><li>Includes the important entities and the relationships among them. </li></ul><ul><li>No attribute is specified. </li></ul><ul><li>No primary key is specified. </li></ul><ul><li>At this level, the data modeler attempts to identify the highest-level relationships among the different entities. </li></ul>Deliverables and Outcome (1)
  9. 9. Deliverables and Outcome (2) <ul><li>Second deliverable is a set of entries about data objects to be stored in repository or project dictionary </li></ul><ul><ul><li>Repository links data, process and logic models of an information system </li></ul></ul><ul><ul><li>Data elements that are included in the DFD must appear in the data model and vise versa </li></ul></ul><ul><ul><li>Each data store in a process model must relate to business objects represented in the data model </li></ul></ul>Conceptual Data Model
  10. 10. จะสร้าง conceptual data model ได้อย่างไร ? (Gathering Information for Conceptual Data Modeling) <ul><li>Two perspectives </li></ul><ul><ul><li>Top-down </li></ul></ul><ul><ul><ul><li>Data model is derived from an intimate understanding of the business </li></ul></ul></ul><ul><ul><li>Bottom-up </li></ul></ul><ul><ul><ul><li>Data model is derived by reviewing specifications and business documents </li></ul></ul></ul>
  11. 11. Top-down perspectives (1)
  12. 12. INVOICE INVOICE ITEM INVENTORY ITEM PRODUCT ORDER SUPPLIER <ul><ul><li>STOCK ON HAND </li></ul></ul><ul><ul><li>AMOUNT ADDED </li></ul></ul><ul><ul><li>INVENTORY LEVELS </li></ul></ul><ul><ul><li>MINIMUM ORDER QUANTITIES </li></ul></ul><ul><ul><li>PAYMENTS </li></ul></ul>Top-down perspectives (2)
  13. 13. INVOICE includes INVOICE ITEM contain INVENTORY ITEM RECIPE PRODUCT request ORDER places SUPPLIER bills Top-down perspectives (3)
  14. 14. INVOICE INVOICE ITEM INVENTORY ITEM PRODUCT ORDER SUPPLIER <ul><ul><li>STOCK ON HAND </li></ul></ul><ul><ul><li>AMOUNT ADDED </li></ul></ul><ul><ul><li>INVENTORY LEVELS </li></ul></ul><ul><ul><li>MINIMUM ORDER QUANTITIES </li></ul></ul><ul><ul><li>PAYMENTS </li></ul></ul>Top-down perspectives (2)
  15. 15. INVOICE includes INVOICE ITEM contain INVENTORY ITEM RECIPE PRODUCT request ORDER places SUPPLIER bills Supplier_ID Supplier_Name Supplier_Addr Invoice_No Vendor_ID Invoice_date Paid? Amount_added Item_no Item_desc Stock on hand Minimum order Qty Inventory_level Product_ID Product_desc Order_No Order_date Order_Qty Top-down perspectives (4)
  16. 16. Practise: Guest (To recognize attributes for entity) <ul><li>Address </li></ul><ul><li>Arrival Date </li></ul><ul><li>Family Name </li></ul><ul><li>GUEST Room Number </li></ul><ul><li>HOTEL Floor Number </li></ul><ul><li>ROOM Number of beds </li></ul><ul><li>STAY Number of parking lots </li></ul><ul><li>Price </li></ul><ul><li>TV set available? </li></ul>
  17. 17. Practise: Guest <ul><li>Address </li></ul><ul><li>Arrival Date </li></ul><ul><li>STAY Family Name </li></ul><ul><li>GUEST Room Number </li></ul><ul><li>HOTEL Floor Number </li></ul><ul><li>ROOM Number of beds </li></ul><ul><li> Number of parking lots </li></ul><ul><li>Price </li></ul><ul><li>TV set available? </li></ul>
  18. 18. Bottom-up perspectives (1) PVF CUSTOMER ORDER ORDER NO: 61384 CUSTOMER NO: 1273 NAME: Contempory Designs ADDRESS: 123 Oak St. CITY STATE:-ZIP: Austin,TX28384 ORDER DATE: 21/01/2006 PROMISED DATE: 31/01/2006 PRODUCT NO. DESCRIPTION QTY_ORDERED UNIT PRICE M128 BookCase 4 200.00 B381 Cabinet 2 900.00 R210 Table 1 500.00
  19. 19. Bottom-up perspectives (1) PVF CUSTOMER ORDER ORDER NO: 61384 CUSTOMER NO: 1273 NAME: Contempory Designs ADDRESS: 123 Oak St. CITY STATE:-ZIP: Austin,TX28384 ORDER DATE: 21/01/2006 PROMISED DATE: 31/01/2006 PRODUCT NO. DESCRIPTION QTY_ORDERED UNIT PRICE M128 BookCase 4 200.00 B381 Cabinet 2 900.00 R210 Table 1 500.00
  20. 20. Bottom-up perspectives (2) <ul><li>ORDER NO </li></ul><ul><li>ORDER DATE </li></ul><ul><li>PROMISED DATE </li></ul><ul><li>UNIT PRICE </li></ul><ul><li>QUANTITY ORDERED </li></ul><ul><li>PRODUCT NO </li></ul><ul><li>DESCRIPTION </li></ul><ul><li>CUSTOMER NO </li></ul><ul><li>NAME </li></ul><ul><li>ADDRESS </li></ul><ul><li>CITY-STATE-ZIP </li></ul>From the form : 1. we determine that the following data must be kept in the database 2. Each order is from one customer 3. An order can have multiple line items, each for one product
  21. 21. ORDER CUSTOMER PRODUCT Order_no Order_date Qty_order Promised_date Unit_price Prod_no Cust_no Prod_desc Cust_name Addr City_state places includes
  22. 22. กรณีที่ได้ relations จาก หลาย user interface
  23. 23. <ul><ul><ul><ul><ul><li>รวม relations ที่ได้ของแต่ละ User Interface ให้เป็น consolidated model </li></ul></ul></ul></ul></ul>
  24. 24. จากข้อมูลสรุปที่ได้จากขั้นตอนการวิเคราะห์ระบบ <ul><li>Moonlight coffees is a fast growing chain of high quality coffee shops with currently over 500 shops in 12 countries of the world. Shops are located at first-class locations, such as major shopping, entertainment an business areas, airports, railway stations, museums. Moonlight coffees has some 9,000 employees. </li></ul><ul><li>Products: </li></ul><ul><li>All shops serve coffees, teas,soft drinks and various kind of pastries. Most shops sell nonfoods, like postcards and sometimes even theatre tickets. </li></ul><ul><li>Make a list of entities that you think are important for Moonlight Coffees. Use your imagination and common sense and use what you find in the summary above. </li></ul>
  25. 25. <ul><li>COUNTRY PRICE </li></ul><ul><li>FOOD CURRENCY </li></ul><ul><li>DRINK STOCK </li></ul><ul><li>PASTRY DEPARTMENT </li></ul><ul><li>PRODUCT EXCHANGE RATE </li></ul><ul><li>LOCATION TYPE </li></ul><ul><li>EMPLOYEE </li></ul><ul><li>และข้อมูลจาก business rules ขององค์กรจะทำให้เราเขียนความสัมพันธ์ระหว่าง entity ได้ </li></ul>การเขียน conceptual data model
  26. 26. <ul><li>Logical Data Model </li></ul><ul><li>Features of logical data model include: </li></ul><ul><li>Includes all entities and relationships among them. </li></ul><ul><li>All attributes for each entity are specified. </li></ul><ul><li>The primary key for each entity specified. </li></ul><ul><li>Foreign keys (keys identifying the relationship between different entities) are specified. </li></ul><ul><li>Normalization occurs at this level. </li></ul><ul><li>At this level, the data modeler attempts to describe the data in as much detail as possible, without regard to how they will be physically implemented in the database. </li></ul>
  27. 27. <ul><li>The steps for designing the logical data model are as follows: </li></ul><ul><li>Identify all entities. ( ใช้ conceptual data model เป็นจุดเริ่มต้น ) </li></ul><ul><li>Specify primary keys for all entities. </li></ul><ul><li>Find the relationships between different entities. </li></ul><ul><li>Find all attributes for each entity. </li></ul><ul><li>Resolve many-to-many relationships. </li></ul><ul><li>Normalization . </li></ul><ul><li>เปลี่ยน E-R Diagrams ให้เป็น Relations </li></ul>
  28. 28. Relational Database Model <ul><li>Data represented as a set of related tables or relations </li></ul><ul><li>Relation </li></ul><ul><ul><li>A named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows </li></ul></ul><ul><ul><li>Properties </li></ul></ul><ul><ul><ul><li>Entries in cells are simple </li></ul></ul></ul><ul><ul><ul><li>Entries in columns are from the same set of values </li></ul></ul></ul><ul><ul><ul><li>Each row is unique </li></ul></ul></ul><ul><ul><ul><li>The sequence of columns can be interchanged without changing the meaning or use of the relation </li></ul></ul></ul><ul><ul><ul><li>The rows may be interchanged or stored in any sequence </li></ul></ul></ul>
  29. 29. Relational Database Model <ul><li>Well-Structured Relation </li></ul><ul><ul><li>A relation that contains a minimum amount of redundancy and allows users to insert, modify and delete the rows without errors or inconsistencies </li></ul></ul>
  30. 30. Normalization <ul><li>The process of converting complex data structures into simple, stable data structures </li></ul>The result of normalization is that every non primary key attribute depends upon the whole primary key
  31. 31. Steps in Normalization
  32. 32. การเปลี่ยน E-R Diagrams ให้เป็น Relations Customer_ID Name C USTOMER Address City_State_ZIP Discount CUSTOMER( Customer_ID ,Name,Address,City_State_ZIP,Discount) <ul><ul><ul><li>แปลง Entities </li></ul></ul></ul><ul><li>ใช้ชื่อของ Entity เป็นชื่อ Relation </li></ul><ul><li>แปลง Identifier ของ Entity มาเป็น Primary Key ของ Relation นั้นๆ Primary Key ของ Weak Entity ต้องรวม Primary Key ของ Entity ที่มันไปขึ้นอยู่ด้วยไว้ใน Primary Key ของ Weak Entity ด้วย </li></ul><ul><li>Attributes ทั้งหมดเป็น non- key attributes </li></ul>
  33. 33. <ul><ul><ul><li>2. แปลง Relationship </li></ul></ul></ul><ul><ul><ul><li>2.1 Binary 1:N and 1:1 relationships </li></ul></ul></ul>CUSTOMER( Customer_NO ,Name,Address, City_State,ZIP,Discount) ORDER( Order_No ,Order_date,Promised_date,Customer_NO) <ul><li>ถ้าเป็น Binary one-to-many relationship (1:N) ให้เอา attribute หรือ attributes ที่เป็น primary key ของ entity ข้างที่เป็น one ไปเป็น foreign key ของข้างที่เป็น many </li></ul><ul><li>ถ้าเป็น Binary หรือ Unary one-to-one relationship (1:1) ให้เลือกว่าจะเอา primary key ของ A เพิ่มเป็น Foreign key ของ B หรือเอา primary key ของ B เพิ่มเป็น Foreign key ของ A หรือทำทั้งสองทาง </li></ul>
  34. 34. <ul><ul><ul><li>2.2 Binary and Higher Degree M:N Relationships </li></ul></ul></ul>ORDER( Order_number ,Order_date,Promised_date) PRODUCT( Product_ID ,Description,Room,……….) ORDER_LINE( Order_Number,Product_ID ,Quantity_Ordered) <ul><li>Entity A และ Entity B มีความสัมพันธ์แบบ M: N relationship (or associative entity) </li></ul><ul><li>สิ่งที่ต้องทำในการแปลงคือสร้าง relation ใหม่ (relation C) ให้มี Primary key ที่มาจาก primary key ของทั้ง A และ B </li></ul>
  35. 35. <ul><ul><ul><li>2.3 Unary Relationships </li></ul></ul></ul>EMPLOYEE( Emp_ID ,Name,Birthdate,Manager_ID) ITEM(Item_Number,Name,Cost) ITEM_BILL(Item_Number,Component_Number,Quantity) <ul><li>เป็นความสัมพันธ์ระหว่าง Instances ของ entity เดียวกัน (recursive relationships) ใช้หลักการเดียวกันกับที่กล่าวมาแล้วในข้อ 2.1 และ 2.2 และใช้ recursive foreign key </li></ul>
  36. 36. Physical Data Model (1) <ul><li>Physical database design results in converting relations into tables </li></ul><ul><ul><li>Based upon results of logical database design </li></ul></ul><ul><ul><li>Key decisions </li></ul></ul><ul><ul><ul><li>Choosing format for each attribute from the logical database model </li></ul></ul></ul><ul><ul><ul><li>Grouping attributes from the logical database model into physical records/rows </li></ul></ul></ul><ul><ul><ul><li>3. Selecting media and structures for storing data to make access more efficient </li></ul></ul></ul>
  37. 37. Physical Data Model (2) <ul><ul><ul><li>Design Fields </li></ul></ul></ul><ul><ul><ul><li>Data Types </li></ul></ul></ul><ul><ul><ul><ul><ul><li>Coding and Compression Techniques </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Controlling Data Integrity </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Null Value control </li></ul></ul></ul></ul></ul><ul><ul><li>Designing Physical Tables </li></ul></ul><ul><ul><ul><li>Has two goals : efficient use of secondary storage and data processing speed </li></ul></ul></ul><ul><ul><ul><li>Whereas Normalization emphasized on well-structured relations. </li></ul></ul></ul>Denormalization
  38. 38. Data Types (1) <ul><li>Objective of choosing Data type : </li></ul><ul><li>Minimize storage space </li></ul><ul><li>Represent all possible values of the field </li></ul><ul><li>Improve data integrity for the field </li></ul><ul><li>Support all data manipulations desired on the field </li></ul>
  39. 39. Data Types (2) Data Coding : Pros – reduce storage space - increase integrity (by restricting input to only a few values) Cons – more difficult to users to remember - program must be written to decode fields before display
  40. 40. Data Types (3) Data Integrity : The value of foreign key CUSTOMER_ID field within a CUST_ORDER must be limited to the set of CUSTOMER_ID values from the CUSTOMER relations. We would not want to accept an order for a non-existing or unknown CUSTOMER.
  41. 41. Data Types (4) Default Value : Null Value Control : - distinct from 0 or blank or any other value - indicate that the value of the field is missing or unknown - ต้องกำหนดว่า field ใดเป็น null ไม่ได้
  42. 42. <ul><li>Physical Data Model (3) </li></ul><ul><li>Features of physical data model include: </li></ul><ul><li>Specification all tables and columns. </li></ul><ul><li>Foreign keys are used to identify relationships between tables. </li></ul><ul><li>Denormalization may occur based on user requirements. </li></ul><ul><li>Physical considerations may cause the physical data model to be quite different from the logical data model. </li></ul>
  43. 43. <ul><li>The steps for physical data model design are as follows: </li></ul><ul><li>Convert entities into tables. . </li></ul><ul><li>Convert attributes into columns. </li></ul><ul><li>Modify the physical data model based on physical constraints / requirements. </li></ul>
  44. 44. Table Specification Name Description Type Length Value/Range Notes/Remarks Table Name : BankAccount PK : ACCT_NO FK : ACCT_NO เลขที่บัญชี CHAR 7 0-9 Format: nnn-nnnn ธนาคารของลูกค้า Unique Not Null AMOUNT ยอดเงินที่เบิก NUMERIC 5 ,2 0 -10,000 Not Null Must <= BALANCE BALANCE ยอดเงินคงเหลือ ..... ...... ......... ....... ในบัญชี .... ..... .... .... .... ....
  45. 45. <ul><li>Normalized Product Relation </li></ul><ul><li>PRODUCT( Product_ID ,Description,Drawing_Number,Weight,Color, </li></ul><ul><li>Unit_Cost,Burden_Rate,Price,Product_manager) </li></ul>Denormalization The process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields. <ul><li>Denormalized Product Relation by columns </li></ul><ul><li>Engineering: E_PRODUCT( Product_ID ,Description,Drawing_Number, </li></ul><ul><li>Weight,Color) </li></ul><ul><li>Accounting: A_PRODUCT( Product_ID ,Unit_Cost,Burden_rate) </li></ul><ul><li>Marketing: M_PRODUCT( Product_ID ,Description,Color,Price, </li></ul><ul><li>Product_Manager) </li></ul>
  46. 46. <ul><li>Normalized Customer Table by rows </li></ul><ul><li>Denormalized Regional Customer Tables </li></ul>Customer_ID Name Region Annual_Sales 1256 Rogers Atlantic 10,000 1323 Temple Pacific 20,000 1455 Gates South 15,000 1626 Hope Pacific 22,000 2433 Bates South 14,000 2566 Bailey Alantic 12,000 Customer_ID Name Region Annual_Sales 1256 Rogers Atlantic 10,000 2566 Bailey Alantic 12,000 A_CUSTOMER Customer_ID Name Region Annual_Sales 1323 Temple Pacific 20,000 1626 Hope Pacific 22,000 P_CUSTOMER Customer_ID Name Region Annual_Sales 1455 Gates South 15,000 2433 Bates South 14,000 S_CUSTOMER
  47. 47. <ul><li>Two entities with a one-to-one relationship </li></ul>Three common situations where denormalization may be used
  48. 48. <ul><ul><li>A Many-to-many relationship (associative entity) with non key attributes </li></ul></ul><ul><li>Duplication of data – attribute description and excessive updating if duplicated data changes </li></ul>
  49. 49. <ul><li>Reference data </li></ul><ul><li>Several items have the same instructions </li></ul><ul><li>STORAGE INSTRUCTIONS relate only to ITEM table. </li></ul><ul><li>Reducing the number of tables to access </li></ul><ul><li>But creating redundancy and extra data maintenance </li></ul>
  50. 50. Business Rules (1) : <ul><li>Specifications that preserve the integrity of data model </li></ul><ul><li>นักวิเคราะห์ระบบต้องศึกษาข้อมูลเกี่ยวกับ business rules ตั้งแต่ขั้นตอนการวิเคราะห์ระบบงาน (determining requirements) </li></ul><ul><li>Four basic types of business rules are : </li></ul><ul><ul><li>Entity integrity – Each instance of an entity type must have a unique identifier that is not null. </li></ul></ul><ul><ul><li>Referential integrity constraints – Rules concerning the relationships between entity types </li></ul></ul><ul><ul><li>Domains – Constraints on valid values for attributes </li></ul></ul><ul><ul><li>Triggering operations – Other business rules that protect the validity of attributes values </li></ul></ul>
  51. 51. Business Rules(2) :
  52. 52. Designing Controls for Files <ul><li>Backup Techniques </li></ul><ul><ul><li>Periodic backup of files </li></ul></ul><ul><ul><li>Transaction log or audit trail (storing a copy of each changes to a log file) </li></ul></ul><ul><ul><li>Change log (storing a copy of each row before and after it is changed) </li></ul></ul><ul><li>Data Security Techniques </li></ul><ul><ul><li>Coding or encrypting </li></ul></ul><ul><ul><li>User account management </li></ul></ul><ul><ul><li>Prohibiting users from working directly with the data. Users work with a copy which updates the files only after validation checks </li></ul></ul>
  53. 53. Designing Control for files
  54. 55. Exercise ข้อ 1. เขียน sequence dialogue diagram จากจอภาพต่อไปนี้ Welcome Page <ul><li>เมนูหลัก </li></ul><ul><li>Product Information </li></ul><ul><li>Rental Information </li></ul>Product number verification Screen Product information selection screen New Product Request screen Rental Status screen Rental History screen Rental Extension request screen Extension confirmation screen Enter new product comment screen View comment Inventory review
  55. 56. Welcome page Product Information Rental Information Product No Verification Product Selection New Product request Rental status Rental history Enter new Product comment View comment Inventory view Rental extension Extension confirmation 0 3 2 2.1 2.2 2.3 3.1 3.2 2.1.1 2.1.2 2.2.1 3.1.1 1 1 2 2 2 2.1 2.2 2.1 3 3 3.1 3.1.1 system 1 เมนูหลัก 0