Software Engineering

1. Software Engineering ERD: Entity Relationship Diagrams

2. Main techniques of structural modelling Hierarchy of Funtions Entity relationship diagrams Data and their relationships Structure of functions Data flow diagrams Using data to perform the fuctions

3. Entity Relationship Diagrams - Definition Entity relation diagram represents the world in a static approach. It incorporatesthe objects of the world and the relationships between them. Elements: entity relationship

4. Entity Entity is a thing or object which is of importance to us and the information on which must be known or stored. The graphical representaion is a (rectangular) frame with a name of the entity. The name should be given in singular and should be separated from the lower part of the frame.The shape and size of the frame should cater for easy writing inside it and drawing the connecting lines outside it.

5. Entity (2) The name should accurately represent a class or type of things – not its instance. Instead of a name like „Warsaw” or „Minsk” the word „City” should be used as the entity name. City . • Each thing should be represented by a single entity. Each entity should be univocally identifiable.

6. Relationship Relationship is a named, significant relation between two entities. It is always a relationship between two entities. In specific cases it can be a relation between an entity and itself. A relationship has two ends. Each end has the following properties specified: - name, - cardinality/multiplicity, - optionality (optional or required). These properties are described separately for both ends of a relationship.

7. Relationship (2) Relationship is representead by a line (not necessarily straight) linking two frames (a frame with itself). The most frequent relationship is „one to many”. It is required at the end „many” and optional at the end „one Entity2 Entity1 relationship

8. Cardinalities of the Relationships Cardinalities/multiplicities: exacltly one  zero or many  one or many  zero or one  more than one  indeterminate  • At the multiplicity „many” the symbol has a popular name of a Crow’s Foot. • Inside the „O” or „zero” the line can be broken.

9. Names of the Relationships Name is written down with lowercase letters. It is specified differently at each end. If the end is required, it is said that „it must be” or „it must have”. If it is optional, it is said „it can be” or „it must have”. Ticket Passenger issued for / written on

10. Relationships - remarks The relationship must hold for all the instances of the entities In ERD, all the notions are related to the types/classes, not to the instances. Not all the relationships which are possible to be drawn are correct. Not all of them appear equally frequently. Entity Entity2 Entity1 One to many Recurrent, one to many for a hierarchy

11. Attributes An entity can have attributes. An attribute is an arbitrary detail useful to classify, identify, specify the number of express the state of an entity. It is an arbitrary description important to an entity. It can be a text, number, image, smell etc. In data processing we have a habit to concentrate on numbers and texts, but the described reality can be richer.

12. Attributes (2) Attributes are written down below the name of an entity, in singular, in lowercase. Adding attributes is not required, but can be helpful. In the example, an airline can have hundreds of airplanes, buth they all can be of only several types. The registration number can differentiate between entities. Airplane Plane type registration no.year of prod.name codedescription of type / classified for

13. Attributes – remarks An attribute has to describe its own entity, not another entity. For example: the seat numer is an attribute of a boarding pass, a ticket, an airplane, a seat, a passenger or a person? It is an attribute of a seat, although it apperas in many other places.

14. Attributes and entities In the majority of cases, one to eight attributes is enough for an entity If there are more, probably a new entity or relatioship is missing The entity name should not be used in attribute names. This is not necessary, because an attribute describes only one entity. • An attribute of one entity can have only one value at a time. If more values are necessary, another entity should be formed, with a „one to many” relationship to the given entity. This rule is called the 1st Normal Form (1NF) rule.

15. Attributes and entities (2) An attribute should be made an entity if it is a significant thing in itself, with its own relationships and attributes. • The „registration number” has been used as an attribute of an airplane. • This is correct, unless the registration system is not considered in detail. • In this case, we can need more data: „where registered”, „how registered”, „by whom registered”, „was it registered repeatedly?” etc.

16. Identification of entities Each entity must be univocally identified by a combination of attributes and relationships. There can be a single unique (univocal) attribute which identifies the entity. It can be distinguished with a # or with an underlined font. The attributes which can be derived from parts of a unique identifier should be deleted. This rule is called the 2nd Normal Form (2NF) rule. Example: the date of birth can be (easily) derived from the Polish personal identification number PESEL, so it is obsolete to keep both data in an entity.

17. Attributes and entities (3) Example: We have a boarding pass, in which the passenger’s name is written down. The question is: does this name depend on the unique identifier of this boarding pass? Obviously not. The person does not change the name when getting the boarding pass! If an attribute does not depend solely on the unique identifier, then probably an entity or a relationship is missing. The attributes which depend not only on the unique identifier should be deleted. This rule is called the 3rd Normal Form (3NF) rule.