1 / 24

Measurable Properties

Measurable Properties. A person may have a large number of properties that are quantitative. PERSON. Name Blood pressure Weight Length Age Shoe size Temperature IQ EQ. Representing all these properties in a schema can make it exceedingly large. Measurement Pattern.

lmcclure
Download Presentation

Measurable Properties

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. Measurable Properties A person may have a large number of properties that are quantitative. PERSON Name Blood pressure Weight Length Age Shoe size Temperature IQ EQ Representing all these properties in a schema can make it exceedingly large.

  2. Measurement Pattern Phenomenontype 1 * 1 * 1 Object Measurement Quantity * The Measurement Pattern enables a compact representation of quantitative properties. A measurement measures the quantity of a phenomenon type for a certain object.

  3. Measurement Pattern :Phenomenon type name = temperature :Quantity unit = Celsius value = 37.5 :Object name = ‘Peter’ :Measurement date = 000101 This instance diagram states that Peter has the temperature 37.5 degrees Celsius 000101.

  4. Category Observation Some properties are not quantitative, but rather classify objects into different groups, for example the gender or nationality of a person. Phenomenontype 1 * 1 * 1 Category observation * Object Category

  5. Category Observation :Phenomenon type name = gender :Category value = male :Object name = ‘Peter’ :Category observation date = 000101 This instance diagram states that Peter has the gender male 000101.

  6. Observation Pattern Measurements and category obser-vations can be combined into one pattern. Phenomenontype 1 * 1 * Object Observation Category observation Measurement * * 1 1 Quantity Category

  7. Employment PERSON We can model the fact that a person is employed at some organisation by including a number of attributes in a type PERSON. However, a person may be employed at several different organisations. In order to handle such a situation, the model has to be expanded. Name Age Address Employer Date of employment

  8. TIME PERIOD ORGANISATION PERSON EMPLOYMENT Name Address Name Age Address Salary From To Employment 1 * * * employer 1 employee 1

  9. 1 * * * employer 1 employee 1 EMPLOYMENT PERSON TIME PERIOD ORGANISATION Name Address Name Age Address Salary From To Employment This model expresses that there exists a responsibility between two parties, the employer and the employee. Similar responsibilities may exist in many other contexts.

  10. PARTY PERSON ACCOUNTABILITY ORGANISATION TIME PERIOD ACCOUNTABILITY TYPE From To Name Name Address Accountability Pattern 1 * 1 * * * commissioner responsible 1 1

  11. ACCOUNTABILITY ACCOUNTABILITY TYPE PARTY Accountability Pattern The Accountability Pattern can be used to model situations where there exists a relationship of responsibility between two parties: - Employment - Order - Contract - Membership - Offering ACCOUNTABILITY TYPE specifies different kinds of accountability. In an employment context, it could contain: permanent employment, project employment, time limited employment, etc.

  12. Accountability :Time period from = 970101 to = 001231 :Accountability type name = permanent :Accountability commissioner responsible :Person name = ‘Peter’ :Organisation name = ‘IBM’ This instance diagram states that Peter is employed by IBM 970101 - 001231.

  13. PROPOSED ACTION IMPLEMENTED ACTION TIME POINT ACTION PARTY LOCATION Action Pattern An action is carried out by a party at a certain point in time at a certain location. An action may be only proposed or it may be implemented, i.e. carried out.

  14. Action Pattern :Time point date = 990101 time = 2.00 a.m. :Time point date = 990101 time = 1.00 a.m. :Proposed action name = surgery :Person name = ‘Peter’ :Implemented action name = ‘Peter’ :Location room = C608 :Location room = C604

  15. RESOURCE Booking Using this simple booking schema, we can express that different resources are booked for different time intervals. In some situations, we do not want to book a specific resource, but rather a general resource type. For example, we only state that we want to book an anaesthesia nurse, it does not matter who. In other cases, we really want to book a specific nurse, say Ed Wallen. BOOKING From To * for 1

  16. Assets and other Resources Some resources are consumed in an activity, e.g. in a surgery blood plasma is consumed. Other resources are not consumed in an activity but can be reused. For example, a nurse is not consumed in a surgery.

  17. ASSET TYPE RESOURCE TYPE ASSET GENERAL RA SPECIFIC RA Resource Allocation Pattern 1 * 1 1 * TEMPORAL RESOURCE RESOURCE ALLOCATION From To Quantity 1 * *

  18. Resource Allocation Three bags of blood plasma are allocated - we do not care which ones. Peter is allocated for two hours. :Asset Type name = Nurse :Asset name = ‘Peter’ :Resource Type name = Blood plasma :Temporal Resource from = 0101, 04 to = 0101, 06 :General RA quantity 3 :Specific RA

  19. Exercise The Resource Allocation Pattern has a number of limitations. Identify these and construct an extension of the pattern that overcomes these limitations. Consider whether it would be worthwhile to have several variants of the pattern to cover different situations.

  20. PROPOSED ACTION IMPLEMENTED ACTION ACTION RESOURCE ALLOCATION Action and Resource Allocation A proposed action books resources, while an implemented action uses resources. uses books

  21. PLAN PROPOSED ACTION Plans The simplest way to model a plan is to say that it consists of a number of proposed actions. Example: Plan for dinner party consists of buying food, cooking, and making the table. One limitation of this model is that we cannot express dependencies between proposed actions, i.e. that certain actions have to be performed before others. * contains *

  22. PLAN ACTION REFERENCE PROPOSED ACTION Plan Pattern By adding a type ACTION REFERENCE, we can express precedence relationships among proposed actions in a plan. We can also add descriptions of the role of an action within a plan, e.g. whether it is optional or not. 1 contains * * precedes 1

  23. VEHICLE BIKE TRUCK BOAT CAR Subtypes One way to show different categories is to introduce a number of subtypes. However, such a solution may result in a very large schema.

  24. VEHICLE VEHICLE TYPE Powertypes VEHICLE TYPE would have instances such as: Car, Truck, Boat, Bike, MC, Aeroplane, ... 1 * VEHICLE would have instances such as: abc123 (which is a Car), vv22 (which is a Boat), ...

More Related