Description and exemplification of entity/event modelling.

1. Description and exemplification of entity/event modelling. • Index and Key • The Index/Key column of the data dictionary is used to indicate whether or not the data item is to be indexed and if it is to be indexed, whether or not the data item is a primary key or a foreign key. • Indexing • Database systems take advantage of indexing to increase their speed. A database index can speed up a query by hundreds or thousands of times. • Indexing is the notion of storing data on a hard disk in a particular way in order to locate and retrieve the data as efficiently as possible. • Keys • When a data item is marked as indexed, the analyst must indicate if indexing is due to the fact that the data item is a primary key (PK) or if it is because the data item is a foreign key (FK) . • Where a foreign key is part of a primary key, both of these facts should be indicated in the data dictionary.

2. Description and exemplification of entity/event modelling. • There are two types of entity/event modelling: • Entity Event Matrix & • Entity Life History.

3. Description and exemplification of entity/event modelling. • Purpose of an Entity Event Matrix • An Entity Event Matrix is used to record a list of all permissible events that can occur and shows the effect that these events have on the entities within the system. • In this context, an event is something that triggers a process into updating data within the system. An effect is the change caused by the event such as the creation, deletion or modification of an entity occurrence.

4. Description and exemplification of entity/event modelling. • One single Entity Event Matrix is created for the entire system. This matrix lists all entities in the system across the top of the matrix. • The events that occur are listed on separate rows of the matrix. Within the matrix, the effect caused by an event is recorded as follows: • C • This is used to indicate that the described event causes a new entity occurrence (or new row of the table) to be created within the entity indicated. • D • This is used to indicate that the described event causes an existing entity occurrence (or existing row of the table) to be deleted from the entity indicated. • M • This is used to indicate that the described event causes existing data values within the entity indicated to be modified. • R • This is used to indicate that the described event causes data values held within the entity indicated to be read by the process that is triggered by the event. Note that read activity is only possible because of the use of foreign keys to link one entity to another. When a data value in an entity is updated, it is possible any entity that has a foreign key link to that entity to see the update - in other words, the linked entity can read the updating that takes place in the main entity. Read activity is also needed to carry out calculations and to produce invoices, statements and reports.

5. Description and exemplification of entity/event modelling. • Creating an Entity Event Matrix • To create an Entity Event Matrix for a particular system, the following steps should be followed: • Create the headings for the matrix remembering that one column is needed to list the events that can occur and a separate column is needed for each entity. • Write down a list of events that can occur in the real world and will trigger a process to be carried out within the system. In carrying out the process, entities within are affected in some way. • Work through the events in the list one at a time and consider how each entity will be affected by the event described. Use the symbols C, D, M and R to record the effect of each event on individual entities. Remember that one single event can cause several entities to be altered in some way.

6. Description and exemplification of entity-relationship modelling. • Entity Life Histories: • sequence, • iteration, • selection. • Description and exemplification of dataflow modelling using level 0 and level 1 data flow diagrams: • system boundary, • environment, • data flow, • physical flow, • data store, • external entity, • process.

7. Entity Life Histories • Entity Life Histories: • An Entity Life History Diagram is used to record the permissible sequence of events that can occur within any one entity. It also indicates which events are repeated and those events that are alternatives. • Each entity must have a separate Entity Life History Diagram. This means that there may be several Entity Life History Diagrams for any one information system. • The events shown on an Entity Life History Diagram must match those recorded in the Entity Event Matrix for the system.

8. Entity Life Histories • Entity Life Histories: • Events shown in an Entity Life History (ELH) Diagram are read from left to right. Events on the left of the diagram must occur before those on the right. • Each branch of an ELH diagram shows a separate category of events. Three different categories of event can be shown in an ELH: • creation events • modification events • deletion events • Events that cause read activity are not shown in an Entity Life History Diagram. Each level of the diagram shows additional detail of an event or an event category.

9. Entity Life Histories • Entity Life Histories: • To create an Entity Life History Diagrams for a particular system, the following steps should be followed: • Create the Entity Event Matrix for the system. • Consider each entity within the matrix separately. • Draw a box to represent the entity at the top level of the diagram. • Look down the column of the Entity Event Matrix that represents the entity and decide which category of events are to be shown on the second level of the ELH. Remember that only 3 categories of events can be shown: Creation, Modification and Deletion. Draw a box for each category present. • Complete each branch of the ELH separately. Remember to pay attention to the use made of * to indicate repetition and the use of o to indicate alternative events. • Repeat steps 3 - 5 for each entity in the system.