Download presentation
Presentation is loading. Please wait.
Published byErin Palmer Modified over 9 years ago
1
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury salisbury@udayton.edusalisbury@udayton.edu (email) http://www.davesalisbury.com/http://www.davesalisbury.com/ (web site)
2
Objectives of logical design... Translate the conceptual design into a logical database design that can be implemented on a chosen DBMS Input: conceptual model (ERD) Output: relational schema, normalized relations Resulting database must meet user needs for: Data sharing Ease of access Flexibility
3
Relational database components Data structure Data organized into tables Data manipulation Add, delete, modify, and retrieve using SQL Data integrity Maintained using business rules
4
Why do I need to know this? Mapping conceptual models to relational schema is straight-forward CASE tools can perform many of the steps, but.. Often CASE cannot model complexity of data and relationship (e.g., ternary relationships, supertype/subtypes) There are times when legitimate alternates must be evaluated You must be able to perform a quality check on CASE tool results
5
Some rules... Every table has a unique name. Attributes in tables have unique names. Every attribute value is atomic. Multi-valued and composite attributes? Every row is unique. The order of the columns is irrelevant. The order of the rows is irrelevant.
6
The key... Relational modeling uses primary keys and foreign keys to maintain relationships Primary keys are typically the unique identifier noted on the conceptual model Foreign keys are the primary key of another entity to which an entity has a relationship Composite keys are primary keys that are made of more than one attribute Weak entities Associative entities
7
Implementing it Instance Attribute Entity Field
8
What about relationships?
9
Constraints Domain constraints Allowable values for an attribute as defined in the domain Entity integrity constraints No primary key attribute may be null Operational constraints Business rules Referential integrity constraints
10
Referential integrity constraint Maintains consistency among rows of two entities matching of primary and foreign keys Enforcement options for deleting instances Restrict–don’t allow delete of “parent” side if related rows exist in “dependent” side Cascade–automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted Set-to-Null–set the foreign key in the dependent side to null if deleting from the parent side not allowed for weak entities
11
Transforming the EER diagram into relations The steps: Map regular entities Map weak entities Map binary relationships Map associative entities Map unary relationships Map ternary relationships Map supertype/subtype relationships
12
Transforming E-R diagrams into relations Mapping regular entities to relations Simple attributes: E-R attributes map directly onto the relation Composite attributes: Use only their simple, component attributes Multivalued Attribute–Becomes a separate relation with a foreign key taken from the superior entity
13
Mapping simple attributes
14
Mapping composite attributes
15
Mapping multi-valued attributes
16
Mapping weak entities Becomes a separate relation with a foreign key taken from the superior entity Primary key composed of: Partial identifier of weak entity Primary key of identifying relation (strong entity)
17
Mapping a weak entity
18
Looks like this using relational schema notation
19
Transforming E-R diagrams into relations Mapping binary relationships One-to-many - primary key on the one side becomes a foreign key on the many side Many-to-many - create a new relation (associative entity) with the primary keys of the two entities as its primary key I like to call these intersection entities to distinguish them from associative entities created at the conceptual level One-to-one - primary key on the mandatory side becomes a foreign key on the optional side
20
Example of mapping a 1:M relationship
21
Looks like this using relational schema notation
22
Example of mapping an M:N relationship
23
Looks like this using relational schema notation
24
Mapping a binary 1:1 relationship
25
Looks like this using relational schema notation
26
Mapping associative entities Identifier not assigned Default primary key for the association relation is the primary keys of the two entities Identifier assigned It is natural and familiar to end-users Default identifier may not be unique
27
Mapping an associative entity with an identifier
28
Looks like this using relational schema notation
29
Associative entity with identifier
30
Maps thusly to relational notation
31
Mapping unary relationships One-to-many - recursive foreign key in the same relation Many-to-many - two relations: One for the entity type One for an associative relation in which the primary key has two attributes, both taken from the primary key of the entity
32
For example...
33
Would look like...
34
And..
35
Would look like...
36
Mapping ternary (and n-ary) relationships One relation for each entity and one for the associative entity
37
Mapping a ternary (and n-ary) relationship
38
Looks like this using relational schema notation
39
Mapping Supertype/subtype relationships Create a separate relation for the supertype and each of the subtypes Assign common attributes to supertype Assign primary key and unique attributes to each subtype Assign an attribute of the supertype to act as subtype discriminator
40
Mapping supertype/subtype relationships
41
Would look like this...
42
Data normalization Normalization is a formal process for deciding which attributes should be grouped together in a relation Objective: to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data Definition: the process of decomposing relations with anomalies to produce smaller, well-structured relations
43
Well-structured relations Well-structured relations contain minimal redundancy and allow insertion, modification, and deletion without errors or inconsistencies Anomalies are errors or inconsistencies resulting from redundancy Insertion anomaly Deletion anomaly Modification anomaly
44
Steps in normalization
45
Functional dependencies and keys Functional dependency: the value of one attribute (the determinant) determines the value of another attribute A -> B, for every valid instance of A, that value of A uniquely determines the value of B Candidate key: an attribute or combination of attributes that uniquely identifies an instance Uniqueness: each non-key field is functionally dependent on every candidate key Non-redundancy
46
First normal form No multi-valued attributes. Every attribute value is atomic. Any valid table is in first normal form.
47
Table with multivalued attributes, not in 1st normal form
48
Table with no multivalued attributes and unique rows, in 1st normal form
49
Anomalies in this Table Insertion–if new product is ordered for order 1007 of existing customer, customer data must be re-entered, causing duplication Deletion–if we delete the Dining Table from Order 1006, we lose information concerning this item's finish and price Update–changing the price of product ID 4 requires update in several records These anomalies exist because there are multiple themes (entity types) in one relation, resulting in duplication and an unnecessary dependency between the entities.
50
Second normal form 1NF and every non-key attribute is fully functionally dependent on the primary key. Every non-key attribute must be defined by the entire key, not by only part of the key. No partial functional dependencies.
51
Order_ID Order_Date, Customer_ID, Customer_Name, Customer_Address Customer_ID Customer_Name, Customer_Address Product_ID Product_Description, Product_Finish, Unit_Price Order_ID, Product_ID Order_Quantity Invoice functional dependency diagram (partial dependencies, therefore not in 2NF)
52
Partial dependencies are removed, but there are still transitive dependencies Removing partial dependencies
53
Third normal form 2NF and no transitive dependencies (functional dependency between non-key attributes.) This is called transitive, because the primary key is a determinant for another attribute, which in turn is a determinant for a third Non-key determinant with transitive dependencies go into a new table; non-key determinant becomes primary key in the new table and stays as foreign key in the old table
54
Transitive dependencies are removed Removing transitive dependencies
55
Merging Relations View Integration–Combining entities from multiple ER models into common relations Issues to watch out for when merging entities from different ER models: Synonyms–two or more attributes with different names but same meaning Homonyms–attributes with same name but different meanings Transitive dependencies–even if relations are in 3NF prior to merging, they may not be after merging Supertype/subtype relationships–may be hidden prior to merging
56
Enterprise Keys Primary keys that are unique in the whole database, not just within a single relation Corresponds with the concept of an object ID in object-oriented systems
57
a) Relations with enterprise key b) Sample data with enterprise key Enterprise keys
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.