CMPT 354 Database Systems I

Transcription

1 CMPT 354 Database Systems I Chapter 2 Entity Relationship Data Modeling

2 Data models A data model is the specifications for designing data organization in a system. Specify database schema using a data model. Object oriented data models: E-R (Entity-Relationship) Model UML Class Model ODL (Object Definition Language) Record oriented data models: Relational model Network model, hierarchical model Visual Models

3 Details of Database Design 1. Requirements analysis o o o What data do we need to model? What kind of database operations to support? What are the most common queries? 2. Conceptual design o o o What are the entities and relationships taken from the requirements? What information does each entity and relationship posses? What constraints and business rules to hold?

4 Details of Database Design 3. Logical schema design o o o What DBMS/logical schema model to use? How to convert the visual design to logical schema? What constraints ensure data consistency? 4. Physical schema design o o o Which attributes need to be indexed? Is it possible to redesign the logical schema to improve efficiency? Which hardware to use?

5 Entity-Relationship Model Why do we need an abstract model? Is more simplistic in some ways Need to design first, but other models are used for schema programming directly. The basic E-R Diagram was conceived by Peter Chen in 1976 as a unifying data model for all data models that existed at that time. Many extensions exist to E-R E-R has many variations. The components of E-R model are: Entity sets Relationship sets Attributes Constraints

6 Entity Sets Entity: any abstract object distinguishable from other objects. (e.g. PM Harper) Entity Set: a collection of similar entities. (e.g. Canadian MPs) Attributes are used to describe an entity set All entities in an entity set have the same attributes. Attributes assume atomic values (e.g. string, integer, real numbers). Entity sets are drawn as named rectangles, attributes as named ovals.

7 Entity Sets Example Name Address SSN Phone clients

8 Relationship Sets Relationship: A connection among two or more entities. E.g. Harper works in the government. Relationship Set: A collection of similar relationships among one or more entity sets. An N-ary relationship set R relates entity sets E 1 E N. Each relationship r R associates entities e 1 E 1 e N E N. Most relationships are binary. Relationship sets are drawn as named diamonds.

9 Relationship Sets Example SSN name address phone Acct # balance clients hold accounts

10 Relationship Roles An entity set can have many relationships with different entity sets, or with itself. When an entity set has a relationship to itself each link must have a role name. Without roles we have ambiguity. SSN name address clients phone Primary Joint Joint Account

11 Relationship Attributes A relationship can also have attributes. Attributes on relationship is necessary when the attribute can only be represented for all related entities together. name address phone join date Acct # balance SSN clients hold accounts

12 Multiway Relationships An N-ary relationship, N>2 is a multiway relationship. Multiway relationships can be replaced by binary relationships, but then are less true to the business rules. SSN name address phone join date Acct # balance clients hold accounts bid location branches

13 Subclasses Entity sets can have class hierarchies using a special relationship called an ISA relationship. A isa B means that entity set A is also a B entity set A inherits all of B s attributes, and can define additional attributes. A is a subclass while B is a superclass. A specializes B while B generalizes A. ISA relationship is drawn as an ISA triangle. Why do we want to subclass? Identify entity sets more precisely. Want to add attributes only to a particular subclass.

14 ISA relationship example Acct # balance accounts card # # trans isa interest chequing savings

15 Aggregation Ref: Database Management Systems: sec page 39. It is possible to treat a relationship set as an entity set by aggregating the relationship with related entity sets. Why would we want that? So we can have relationships with relationships. Advantages over ternary relationships: Can have a distinct aggregated relationship with specific attributes. Can specify constraints some multiplicity constraints. Drawn by a dashed rectangular frame for the aggregate group of entity sets and relationship set.

16 Aggregation Example SSN name address phone clients Acct # balance join date joined hold accounts bid location branches

17 Modeling Constraints Constraints can be roughly classified as follows: 1. Keys: unique identifier for each entity in an entity set. 2. Single value constraints that require a value to be unique. 3. Referential Integrity: require that a value being referenced exist in a database. 4. Multiplicity: require that relationship sets have some constrained number of relationship with related entities. Many-to-one relationships (includes one-to-one) Participation constraints (at least one) ISA constraints (Covering and Overlap) Arbitrary multiplicity 5. Domain constraints: the range of each attribute. 6. General constraints: Any checks that have to be verified.

18 Keys A key for an entity set E is a set K of one or more attributes such that for every two entities e 1, e 2 E, e 1 (K) e 2 (K). That is, the attributes in K are different for both entities Uniqueness. Every entity must have a key. A key can have more than one attribute. An entity set can have many candidate keys. We choose only one preferred key called primary key. Each entity in an ISA hierarchy is uniquely identifiable by the key of the root entity set. Primary keys are drawn as underlined attributes.

19 Primary Key Example SSN name address phone join date Acct # balance clients hold accounts univeristy course # instructor # students semester section courses

20 Multiplicity Constraints on number of times an entity can participate in a relationship. Four possible set mappings. We say a relationship R from entity sets A to B is: 1. Many-to-many each member of A can connect to any member of B any number of times. (no restriction on R) 2. Many-to-one each member of A can connect to at-most one member of B. 3. One-to-Many R is many-to-one from B to A. 4. One-to-One R is both many-to-one and one-to-many from A to B. One-to-many relationships are drawn with an arrow pointing at the One entity set.

21 Multiplicity Example SSN name address phone join date Acct # balance clients hold accounts bid location branches Clients can only join one branch, and accounts can only be opened at one branch, but the diagram in this example represents something less restrictive. The restriction is on a combination of clients and accounts.

22 Participation Constraints A participation constraint indicates that at least one entity of an entity set must participate in a relationship. Drawn with a thick link. For example, if clients are kept after account is closed: name address phone join date Acct # balance SSN clients hold accounts Drawing this constraint is not required for the course!

23 Arbitrary Multiplicity Want to specify an arbitrary number restriction on the times an entity can be in a relationship with a single related entity. Draw in math notation on the links. name address phone course # section SID students registered for <=5 courses

24 Referential Integrity Entity set A has referential integrity constraint with respect to entity set B if for every entity in A there must be exactly one referenced entity in B. That is when R is a relationship from A to B, then for every a A there must exist some related b B. Rules needed for database operations on A and B: Deleting tuples in B. Inserting tuples in A. Modifying tuples in A and B. Drawn with a rounded arrowhead.

25 Referential Integrity Example Example if joint accounts are represented separately: SSN name address phone join date Acct # balance clients hold accounts primary joint with joint

26 Weak Entity Set A weak entity set cannot be uniquely identified without attributes of another entity set the owner entity set. The key for the weak entity set must include the keys from its owners which are called foreign keys. Identifying attributes from the weak entity set can be combined with keys from owner entity sets to form a key for the weak entity. The relationships between a weak entity set and its owners are called supporting(/identifying) relationships. Weak entity sets commonly arise as hierarchical classifications other than isa, or connecting sets.

27 Weak Entity Set Rules Supporting relationships must be binary, many-to-one or one-to-one relationships. The weak entity set has a foreign integrity constraint with respect to its owners. Draw a weak entity set or supporting relationships by double borders. Acct # balance type amount accounts lends Mortgage

28 Design Principles Faithfulness Model the system aspects as specified. Model as much requirements as possible, not all constraints are possible to be captured in E-R diagrams. Avoiding Redundancy Try to store information only at a single location. Redundancy can lead to: Messy E-R diagrams Increased storage requirements Increased modification time and unreliability. Can help speed up some queries and slow down others.

29 Design Choices Simplicity Avoid introducing unnecessary elements. Complex design is harder to follow and implement. Prefer attributes over entities if all else the same. Design Choices Should we model a concept as an attribute or an entity set? Should the concept be modeled as an entity set or a relationship set? What type of relationship to choose? Binary vs. Ternary or higher arity, aggregation? What are the constraints: multiplicity, referential integrity, weak entity set?

30 Choosing Element Types An attribute is simpler to implement than an entity set. An entity set E can be replaced by an attribute if: E is involved only in one-to-many relationships. All the attributes of E are part of the key. E does not participate in any relationship twice. How to replace by attribute? For binary relationships: attribute on entity set. For multiway relationships: attribute on relationship set. Why must all attributes of E be key? Why must E only be in one-to-many relationships? Similar preference for attribute can be on relationships.

31 Attribute vs. Entity Example street city addresses country join date SSN name address lives phone account join date dates Acct # balance clients hold accounts

32 Choosing Relationship Type Some data models require only binary relationships. Avoid redundancy of reference by induction. clients hold accounts joined branches opened Requirements dependent, different relationships have different semantics/constraints. Binary relationships are generally more expressive. How to convert Ternary relationship to Binary?

33 Relationship Type Example SSN name address phone join date Acct # balance clients hold accounts bid location branches

34 Relationship Type Example name address phone bid location Acct # balance SSN clients branches accounts have created join date owned by holdings