Vous êtes sur la page 1sur 13

n.

) Also called an entity-relationship model, a graphical representation of entities and their relationships to each other, typically used in computing in regard to the organization of data within databases or information systems. An entity is a piece of dataan object or concept about which data is stored. A relationship is how the data is shared between entities. There are three types of relationships between entities:

one-to-one: one instance of an entity (A) is associated with one other instance of another entity ( ). !or e"ample, in a database of employees, each employee name (A) is associated with only one social security number ( ). one-to-many: one instance of an entity (A) is associated with zero, one or many instances of another entity ( ), but for one instance of entity there is only one instance of entity A. !or e"ample, for a company with all employees wor#ing in one building, the building name (A) is associated with many different employees ( ), but those employees all share the same singular association with entity A. many-to-many: one instance of an entity (A) is associated with one, zero or many instances of another entity ( ), and one instance of entity is associated with one, zero or many instances of entity A. !or e"ample, for a company in which all of its employees wor# on multiple projects, each instance of an employee (A) is associated with many instances of a project ( ), and at the same time, each instance of a project ( ) has multiple employees (A) associated with it.

http:$$www.smartdraw.com$tutorials$software$erd$erdcardinality.htm

Data Model Cardinality


%ardinality defines the numeric relationships between occurrences of the entities on either end of the relationship line. &ere are some e"amples:

LINK This is a ':' optional relationship basically stating that a person can occupy one par#ing space, that ( don)t need a person to ha*e a space and ( don)t need a space to ha*e a person. Although the concept is fairly simple, a database can)t e"press it directly. +ou would need to nominate one entity to become the dominant table and use triggers or programs to limit the number of related records in the other table.

SubType This is a ,:' relationship- optional only on one side. This would indicate that a person might be a programmer, but a programmer must be a person. (t is assumed that the mandatory side of the relationship is the dominant. Again, triggers or programs must be used to control the database.

Physical Se ment This is a ,:, mandatory relationship and demonstrates a segmentation denormalization. A person must ha*e one and only one ./A pattern and that pattern must apply to one and only one person. This is difficult to implement in a database, since declarati*e referential integrity will get caught in a 0%hic#en and the 1gg0 situation. asically, this is a single entity.

Possession This is a ':2 (zero to many) optional relationship indicating that a person might ha*e no phone, one phone or lots of phones, and that a phone might be un3owned, but can only be owned by a ma"imum of one person. This is implemented in a database as a nullable foreign #ey column in the phone table that references the person table.

Child This is a ,:2 mandatory relationship, the most common one seen in databases. A person might be a member or might not, but could be found multiple times (if the member entity represents membership in multiple clubs, for instance). A member must be a person, no 4uestions as#ed. The foreign #ey in the member table would be mandatory, or not3null.

Characteristic This is a ':2 relationship that is mandatory on the many side. (t indicates that a person must ha*e at least one name, but possibly many names, and that a name might be assigned to a person (might not) but at most to one person. (n a database you would ha*e the the name table with a nullable foreign #ey to the person table and triggers or programs to force a person to ha*e at least one name.

Parado! This is a ,:2 relationship mandatory on both sides. As with the physical segment situation, the 0%hic#en and the 1gg0 is in*ol*ed since you ha*e to ha*e a person to ha*e citizenship, but citizenship to ha*e a person.

"ssociation This is a 2:2 (many to many) optional relationship. %onceptually, it means that a person might or might not wor# for an employer, but could certainly moonlight for multiple companies. An employer might ha*e no employees, but could ha*e any number of them. Again, not hard to *isualize, but hard to implement. 2ost solutions of this situation in*ol*e creating a third 0Associati*e 1ntity0 to resol*e the 2:2 into two ':2 relationships. This might be an entity called employee because it does lin# the person to the employer the person wor#s for.

5isitors on this page: 6an error occurred while processing this directi*e7 8ast 9pdated: 6an error occurred while processing this directi*e7

#$% T$ D&"% 'NTIT( &'L"TI$NS#IP DI")&"MS 'NTIT( &'L"TI$NS#IP DI")&"MS *'&D) C"&DIN"LIT( N$T"TI$NS
Cardinality %ardinality specifies how many instances of an entity relate to one instance of another entity. :rdinality is also closely lin#ed to cardinality. ;hile cardinality specifies the occurances of a relationship, ordinality describes the relationship as either mandatory or optional. (n other words, cardinality specifies the ma"imum number of relationships and ordinality specifies the absolute minimum number of relationships. ;hen the minimum number is zero, the relationship is usually called optional and when the minimum number is one or more, the relationship is usually called mandatory. There are many notation styles that e"press cardinality and they are all supported by <mart.raw.

In+ormation 'n ineerin

Chen

o ical Data Model 8ogical .ata 2odels (8.2s) represent data table (1ntity Type) relationships.

A Logical Data Model (LDM)

Lo ical Data Model Notations

'ntity Type 1ntity Type refers to a group of related data placed in an =. 2< (=elational .atabase 2anagement <ystems) table. An entity is an instance of an entity type represented as a single row in a data table. 8earn how to con*ert a rectangle into a table. 8earn how to edit te"t on this object. &elationships and Multiplicity =elationships illustrate how two entity types are related. %ardinality specifies how many instances of an entity relate to one instance of another entity. :rdinality is also closely lin#ed to cardinality. ;hile cardinality specifies the occurences of a relationship, ordinality describes the relationship as either mandatory or optional. (n other words, cardinality specifies the ma"imum number of relationships and ordinality specifies the absolute minimum number of relationships. 8earn how to e"press cardinality in <mart.raw.

Child-Parent Mar,ers 9se *C) to indicate that all child entities are deleted if the parent entity is deleted. 9se *&) to indicate that the parent may not be deleted if children e"ist. De+inition- A candidate #ey is a combination of attributes that can be uni4uely used to identify a database record without any e"traneous data. 1ach table may ha*e one or more candidate #eys. :ne of these candidate #eys is selected as the table primary #ey.

Suggested Reading
De+inition- A foreign #ey is a field in a relational table that matches the primary #ey column of another table. The foreign #ey can be used to cross3reference tables De+inition- The primary #ey of a relational table uni4uely identifies each record in the table. (t can either be a normal attribute that is guaranteed to be uni4ue (such as <ocial <ecurity /umber in a table with no more than one record per person) or it can be generated by the . 2< (such as a globally uni4ue identifier, or >9(., in 2icrosoft <?8 <er*er). @rimary #eys may consist of a single attribute or multiple attributes in combination. (magine we ha*e a student records database that contains three tables. The first table, <T9.1/T<, contains a record for each student at the uni*ersity. The second table, %8A<<1<, contains a record for each class session offered. The third table, 1/=:8821/T, contains student enrollment records (e.g. each record represents a single student enrolling in a single course). There would be multiple records for each student (representing all the classes that student is enrolled in) and multiple records for each class session (representing all the students enrolled in that class). A student)s uni4ue student (. number would be a good choice for a primary #ey in the <T9.1/T< table. The student)s first and last name would not be a good choice, as there is always the chance that more than one student might ha*e the same name. Relationships- They describe the association between entities. They are characterised by optionality and cardinality.

Optionality is of two types, namely, mandatory and optional. ,. Mandatory relationship means associated with e*ery instance of the first entity there will be atleast one instance of the second entity. A. Optional relationship means that there may be instances of the first entity, which are not associated with any instance of the second entity. !or e"ample, employee3 spouse relationship has to be optional because there could be unmarried employees. (t is not correct to ma#e the relationship mandatory. Cardinality is of three types: one3to3one, one3to3many, many3to3many. ,. One-to-one relationship means an instance of the first entity is associated with only one instance of the second entity. <imilarly, each instance of the second entity is related to one instance of the first entity. A. One-to-many relationship means that one instance of the first entity is related to many instances of the second entity, while an instance of the second entity is associated with only one instance of the first entity. B. (n many-to-many relationship an instance of the first entity is related to many instances of the second entity and the same is true in the re*erse direction also.
Requirements Engineering Prev Course Contents Next

... 'ntity &elationship Dia ram *'&D) 1=. complements .!.. ;hile .!. focuses on processes and data flow between them, 1=. focuses on data and the relationships between them. (t helps to organise data used by a system in a disciplined way. (t helps to ensure completeness, adaptability and stability of data. (t is an effecti*e tool to communicate with senior management (what is the data needed to run the business), data administrators (how to manage and control data), database designers (how to organise data efficiently and remo*e redundancies). (t consists of three components. Entity- (t represents a collection of objects or things in the real world whose indi*idual members or instances ha*e the following characteristics:

1ach can be identified uni4uely in some fashion. 1ach plays a necessary role in the system we are building. 1ach can be described by one or more data elements (attributes).

1ntities generally correspond to persons, objects, locations, e*ents, etc. 1"amples are employee, *endor, supplier, materials, warehouse, deli*ery, etc. There are five types of entities.

/undamental entity- (t does not depend on any other entity for its e"istence. !or e.g. materials Subordinate entity- (t depends on another entity for its e"istance. !or e"ample, in an in*entory management system, purchase order can be an entity and it will depend on materials being procured. <imilarly in*oices will depend on purchase orders. "ssociati0e entity- (t depends on two or more entities for its e"istence. !or e"ample, student grades will depend on the student and the course. )eneralisation entity- (t encapsulates common characteristics of many subordinate entities. !or e"ample, a four wheeler is a type of *ehicle. A truc# is a type of four wheeler . " re ation entity- (t consists of or an aggregation of other entities. !or e"ample, a car consists of engine, chasis, gear bo", etc. A *ehicle can also be regarded as an aggregation entity, because a *ehicle can be regarded as an aggregation of many parts.

Attributes- They e"press the properties of the entities. 1*ery entity will ha*e many attributes, but only a subset, which are rele*ant for the system under study, will be chosen. !or e"ample, an employee entity will ha*e professional attributes li#e name, designation, salary, etc. and also physical attributes li#e height, weight, etc. ut only one set will be chosen depending on the conte"t. Attributes are classified as entity keys and entity descriptors.

1ntity #eys are used to uni4uely identify instances of entities. Attributes ha*ing uni4ue *alues are called candidate #eys and one of them is designated as primary #ey. The domains of the attributes should be pre3defined. (f )name) is an attribute of an entity, then its domain is the set of strings of alphabets of predefined length.

Relationships- They describe the association between entities. They are characterised by optionality and cardinality. Optionality is of two types, namely, mandatory and optional. ,. Mandatory relationship means associated with e*ery instance of the first entity there will be atleast one instance of the second entity. A. Optional relationship means that there may be instances of the first entity, which are not associated with any instance of the second entity. !or e"ample, employee3 spouse relationship has to be optional because there could be unmarried employees. (t is not correct to ma#e the relationship mandatory. Cardinality is of three types: one3to3one, one3to3many, many3to3many.

,. One-to-one relationship means an instance of the first entity is associated with only one instance of the second entity. <imilarly, each instance of the second entity is related to one instance of the first entity. A. One-to-many relationship means that one instance of the first entity is related to many instances of the second entity, while an instance of the second entity is associated with only one instance of the first entity. B. (n many-to-many relationship an instance of the first entity is related to many instances of the second entity and the same is true in the re*erse direction also. :ther types of relationships are multiple relationships between entities, relationships leading to associati*e entities, relationship of entity with itself, 1C%89<(513:= and A/. relationships ERD notation- There are two type of notation used: ,. @eter Chen notation A. Bachman notation. /ot surprisingly, @eter %hen and achman are the name in*entors of the notation. The following table gi*es the notation.
C$MP$N'NT 1/T(T+ := : D1%T T+@1 &'P&'S'NT"TI$N @9=%&A<1 :=.1=

=18AT(:/<&(@

%A=.(/A8(T+

:@T(:/A8(T+

@1T1= %&1/

A%&2A/

1"ample for achman notation

1"ample for @eter %hen notation

>i*en below are a few e"amples of 1= diagrams using achman notation. !irst the te"tual statement is gi*en followed by the diagram ,. (n a company, each di*ision is managed by only one manager and each manager manages only one di*ision

A. Among the automobile manufacturing companies, a company manufactures many cars, but a gi*en car is manufactured in only one company

B. (n a college, e*ery student ta#es many courses and e*ery course is ta#en by many students

E. (n a library, a member may borrow many boo#s and there may be boo#s which are not borrowed by any member

F. A teacher teaches many students and a student is taught by many teachers. A teacher conducts e"amination for many students and a student is e"amined by many teachers.

G. An e"tension of e"ample3B abo*e is that student3grades depend upon both student and the course. &ence it is an associati*e entity

H. An employee can play the role of a manager. (n that sense, an employee reports to another employee.

I. A tender is floated either for materials or ser*ices but not both.

J. A car consists of an engine and a chasis

Prev

Up %ourse %ontents

Next

Vous aimerez peut-être aussi