1 / 42

Efficient Data Management for Business Information Requirement

Learn about the data management approach to transfer business information requirements into an operational database through data modeling and database design.

apontej
Download Presentation

Efficient Data Management for Business Information Requirement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Data Management(資料管理) Employ database development approach to transfer business information requirement into an operational database.

  2. Data Management • Data Modeling 分析/模式化資料 • Database Design 將資料模式轉為資料庫表格

  3. Data Modeling • Define and model the things of significance about which business needs to know or hold and the relationships between them. 將企業需要知道或保存的資訊,找出較關鍵或有意義的訊息予以模式化,方便日後的管理。

  4. Entity-Relationship Data Model • 關聯式資料庫(Relational Database)設計中較常用的 Data Modeling方式 Data management 的目的 Data Modeling(E-R model) Business Requirements Database Database Design 鬆散、無組織 的資訊 模式化、有組織 的資訊 不易管理 易管理

  5. 有關資料庫 資料庫是一個軟體,其核心部分稱為資料庫管理系統,藉由一資料庫引擎來管理及操作資訊。 至於企業資料的模式與資料擺放在資料庫的位置,需由設計者決定。 資料庫系統 = 資料庫引擎 + 資料的模式 + 資料(含系統資料 及企業資料) + 應用系統(人機介面)

  6. Data Modeling--- 範例 • 背景:某大公司欲建立人事管理系統。 • 系統需求 • 需要 keep and track每一位員工的資料,包括:姓名、職務、到職日、薪資。 • 每一位員工有一個員工代號。 • 公司分成幾個部門,每位員工屬於一個部門,需要知道員工所屬的部門及其主管與部門所在的位置。 • 有些員工是主管,想查每位主管的部屬。

  7. E-R Model E-R model is to develop an entity-relationship model that represents the information of the business. Business requirement Entity Relationships Entity Entity Entity

  8. DEPARTMENT EMPLOYEE #* empno * name 。 job * hiredate 。salary #* depno * name * mgrno 。location A Sample E-R Model RELATIONSHIP assigned to responsible for ENTITY

  9. E-R名詞定義 • Entity the things of significance about which information needs to be known or held. • Relationship how the things of significance(entities) are related • Attributes the specific information which needs to be held

  10. E-R modeling: figure out Entities (their corresponding Attributes) and the Relationships between them among business requirements. Things To Do • Identify Entities. • Fill up Attributes for each Entity. • Figure out relationships among Entities.

  11. IDENTIFY ENTITIES(from business requirements) • What could be an Entity? • An object of interest • a class or category of thing • a named thing • The Characteristics of Entity: • Each entity must have multiple instances. • Each instance must be uniquely identifiable from other instances of the same entity.

  12. EMPLOYEE #* empno * name 。 job * hiredate 。salary Entity Diagramming Notations ENTITY Name 大寫 Attributes 小寫 • Once an entity is identified, the specific piece of information • that describe it(the entity) are called Attributes.

  13. The Characteristics of Entity • Each entity must have multiple instances. instance or occurrence

  14. The Characteristics of Entity (續) • Each instance must be uniquely identifiable from other instances of the same entity. An attribute or a set of attributes that uniquely identify an entity is called a Unique Identifier (UID). E.g. the empno of EMPLOYEE the depno of DEPARTMENT

  15. Identify Entity : Step By Step(from Business Requirment) • Examine the nouns. Are they things of significance. • Name each entity. • Is there information of interest about the entity. • Which attribute or attributes could serve as UID. • Diagram each entity and its attributes.

  16. ENTITY & RELATIONSHIP Business Requirements (零亂的資訊) Importance, things of significance, class, …..

  17. Relationship Def:A relationship is a two-directional, significant association between two entities, or between an entity and itself. Ex. Each COURSE must betaught byone and only one INSTRUCTOR. Each INSTRUCTOR may teachone or many COURSEs. Relationship optionality degree name

  18. Relationship Diagramming Notations • A line between two entities. • Lower case relationship names. • Optionality • ---------- optional(may be) • ________ mandatory(must be) • Degree One and only one one and more

  19. Relationship: By Example(1) name INSTRUTOR COURSE assigned to responsible for ENTITY ENTITY degree optionality

  20. Relationship: By Example(2) EMPLOYEE PAYCHECK for the receiver of Each PAYCHECK must be for one and only one EMPLOYEE Each EMPLOYEE may be the receiver of one or more PAYCHECK

  21. Relationship: By Example(3) MOTHERBOARD COMPUTER the host for be incorporated into Each COMPUTER must be the host for one and only one MOTHERBOARD Each MOTHERBOARD may be incorporated into one and only one PAYCHECK

  22. COURSE STUDENT Relationship: By Example(4) enrolled in taken by Each STUDENT may be enrolled in one or more COURSEs Each COURSE may be taken by one or more STUDENT

  23. WAREHOUSE Relationship: Exercise issued for ORDER PROD_ITEM Bought via originated by stored in the repository for the originator of CUSTOMER

  24. Relationship: Solution • Each ORDER must be issued for one or more PROD_ITEMs • Each PROD_ITEM may be bought via one or more ORDER • Each ORDER must be originated by one and only one CUSTOMER • Each CUSTOMER may be the originator of one or more ORDER • Each PROD_ITEMs must be stored at one and only one WAREHOUSE • Each WAREHOUSE may be the repository of one or more PROD_ITEMs

  25. Relationship Type • One-to-one • rare • mandatory in both directions is very rare. • may be the same entity. • many-to-one • very common • mandatory in both directions is rare • many-to-many • very common

  26. Analyze And Model Relationship • Determine the existence of a relationship. • Name each direction of the relationship. • Determine the optionality of each direction. • Determine the degree of each direction. • Validate it.

  27. based on bought from description of operated by represented by responsible for the basis for the supplier of for the operator for the representation of the responsibility of Useful Relationship Name Pairs

  28. Layout of the E-R Diagram • Entity Box 向上對齊。 • Relationship lines 儘量以直線表示,若不得不為斜線,角度應在30o ~ 60o之間。 • 雞爪(crowsfoot) 儘量放在左(上)方的位置。 • 較大的Entity Box (attributes多者)儘量放在左(上)方的位置儘量放在左(上)方的位置。。 • 所有的 relationship都要以文字描述。

  29. STUDENT id name phone address blood_type Attributes • Attributes are information about an entity that needs to be known。 • Attributes describe、classify 、quantify or express the state of the entity 來自需求

  30. STUDENT id name phone address blood_type Determine Attributes(1) • 將 Attribute 的意義拆解至較簡單的型式。 addr_city addr_county addr_street addr_zip

  31. CUSTOMER id name phone address tape_rent Determine Attributes(2.1) • Any attribute should not be multi-valued(多重值). It is equivalent saying no repeating group. Ex. A customer can rent several tapes. These four attributes will repeat for tape-rent

  32. Determine Attributes(2.2) Ex. 差假系統: 記錄員工請假資料 EMPLOYEE id name phone address leave_type leave_date Has multi-values Repeat Group

  33. STUDENT id name phone birthdate age Determine Attributes(3) • No attribute is derived or calculated from the existing values or other attributes. “age” can be determined from “birthdate”. Therefore, all data of “age” are redundant. Redundant data may cause data inconsistent .

  34. ALUMNI id name phone experience Determine Attributes(4) • Attributes 本身不應該具有自己的Attributes. If you may need to know more about “experience”, you can not place it here. E.g. type years place 家教 3年 學生家 experience

  35. ALUMNI * id * name 。phone * email 。fax Determine Attributes(5) • Identify each attribute’s optionality using an attribute tag. * mandatory 。optional Symbols: This is to tell Database Management System which information must be filled, and which information may be absent in the database.

  36. ALUMNI TICKET #* id * name 。phone * email 。fax #* flight_no #* date #。Seat_no * discount Determine Attributes(6-1) • Assign Unique Identifier(UID) • A UID is any combination of attributes and(or) relationships that serve to uniquely identify an occurrence of an entity, e.g. (1) UID

  37. TUTOR EXPERIENCE #* type * year 。place #* id * name 。phone * email 。fax Determine Attributes(6-2) (2) #* tutor_id • The relationship serve as part of UID. • UID = type + tutor_id

  38. ASSIGNMENT TUTOR STUDENT #* id * name 。phone #*id *name *phone *date *pay Determine Attributes(6-3) (3) student_id tutor_id UID No UID by itself #*student_id #*tutor_id

  39. CAR CAR * type * color 。cylinder * price 。export #* id *type * color 。cylinder * price 。export Determine Attributes(7) • Consider creating unique, artificial attributes to help identify an entity, e.g. Not able to pick up UID

  40. Determine AttributesSummary Search for attributes and relationships to identify each entity. • Evaluate the Attributes • What mandatory attributes identify the entity? • Seek out additional attributes that help identify the entity. Consider creating artificial attributes for identification. • Does an attribute uniquely identify the entity? • What combination of attributes uniquely identify the entity?

  41. Determine AttributesSummary(續) • Consider the Relationships • Which of the relationships help identify the entity? • Are there missing relationships that help identify the entity? • Does the relationship help uniquely identify the entity? • Is the relationship mandatory and one and only one in the direction from the entity?

  42. Determine AttributesSummary(續) • Validate the UlD • Examine sample data. Does the selected combination of attributes and relationships uniquely identify each instance of an entity? • Are all the attributes and relationships that are included in the UID mandatory?

More Related