Principles of of Database Design

Size: px
Start display at page:

Download "Principles of of Database Design"

Transcription

1 Database Design Foundations of of Information Management (WS (WS 2008/0 2008/09) Chapter 4? Principles of of Database Design Foundations of IM 1

2 Design of DB applications Relative costs for compensating the consequences of errors: 1 Requirements analysis Database development Design Topic of this chapter Implementation >> >> Usage Foundations of IM 2

3 DB-Design: Design: Phases Application area in the "real world" Design documentation Logical structure on paper" Conceptual design Logical design Conceptual level Logical level Physical structure in storage Physical design Physical level Foundations of IM 3

4 Conceptual design Application area in the "real world" Design documentation Formally define definewhat whatyou youknow about about the the world world without withoutthinking of of computers and and databases (yet (yet)! Conceptual design Conceptual level Logical structure on paper" Logical design Logical level Physical structure in storage Physical design Physical level Foundations of IM 4

5 The Entity-Relationship model Entity-Relationship data model (ER model): Proposed in 1976 in a paper by Peter Chen Graphical notation for application modeling (ER diagrams) Independent semantic data model (aiming at the meaning of concepts in real world) Predecessor of today s object-oriented oriented data models Extremely successful as a means of pre-design of relational DBs The ER model offers few very simple and basic concepts: Entities (objects), characterized by attributes (properties) Binary or n-ary relationships between entities, possibly characterized by attributes as well Often not mentioned explicitly, but important and basic: Values: printable symbols as values of attributes; play a subordinate role (characterizing objects) Roles: Names for the special meaning an entity has within a relationship Foundations of IM 5

6 An entity Each entity is completely characterized by the values of all its attributes. an an entity its itsattributes persnr firstname name age topic rank 765 "Rainer" "Manthey" 53 "Informatik" their "C3" their theirvalues Foundations of IM 6

7 Two similar entities persnr firstname name age topic rank 765 "Rainer" "Manthey" 53 "Informatik" "C3" another entity persnr firstname name age topic rank identical attributes?? Armin B." Cremers" 60 "Informatik" "C4" partially different values Foundations of IM 7

8 Entity types Similar entities can be combined into entity types. Similarity" requires at least identical attribute structure. (Attribute names and corresponding value domains are identical.) Entity types are graphically represented by rectangles.. Attributes label the line connecting an entity type and a value domain (often symbolized by an oval): professor Name of the type persnr firstname name age topic rank Int String String Int String String Foundations of IM 8

9 Entity types: : Alternative representations Domain names are often omitted (in case they are obvious or irrelevant). Instead attributes are placed inside ovals: professor persnr firstname name age topic rank In larger diagrams, the attribute structure is often entirely omitted in order to save space (or is written down in abbreviated form only): professor persnr, firstname, name,,... Foundations of IM 9

10 Instances and population of an entity type Each entity belongs to" at least one entity type: It is called an instance of this type. an instance of professor The set of all current instances of an entity type is calles its current population. a population of professor Foundations of IM 10

11 Multiple classification One and the same entity can be an instance of various entity types. instance of professor instance of fan of Werder Bremen In such a case, the attributes of the different types of this entity may well be quite different. Foundations of IM 11

12 Classification in presence of identical attributes Entities with the same attributes do not at all have to be instances of the same type! instance of Ass name, firstname,, age instance of Fan of football club Werder Bremen name, firstname,, age Almost always additional classification criteria are required, usually not derivable from the attribute structure. Foundations of IM 12

13 Key attributes As in the relational model (Access, SQL), there are usually one or more attributes per entity type the values of which are sufficient for uniquely identifying each instance: Key Key attributes professor persnr firstname name age topic rank (Primary) key attributes are usually underlined in an ER-diagram diagram. Keys ought to be "minimal"" (no attribute can be omitted). A distinction between primary key and other candidate keys is not made in the ER-model model, even though it would be useful to do so. Foundations of IM 13

14 Relationships 2 nd main concept of the ER-model model: elementary relationships between two or more entities (possibly with their own attribute values) Relationship PersNr 765 year of assignment 1992 name Universität Bonn Each relationship is uniquely characterized by the key values of the partici- pating entities and by the values of all relationship attributes. However, there are no separate key attributes for relationships,, as the keys of the participating entities always suffice for unique identification. Foundations of IM 14

15 Multiple relationships Entitites may participate in various relationships (also similar ones). year of assignment 1992 year of assignment 1999 Foundations of IM 15

16 Relationship types Similar relationships may be grouped into relationship types. Similarity" requires at least identical attribute structure and identical types (and number) of participating entities. Relationship types are graphically denoted in the ER-model by a diamond. Attributes are written as for entity types. assigned_to professor university persnr,,... year of assignment name,,... Int Foundations of IM 16

17 Instances of a relationship type assigned_to professor university persnr,,... year of assignment Int name,,... Relationship types have instances, too: Individual relationships between individual entities are analogously considered instances of the corresponding R-type. assigned_to persnr year of assignment 1992 name... Universität Bonn Foundations of IM 17

18 Type vs. instance assigned_to professor university persnr,,... entity type type year of assignment Int name,,... relationship type type The distinction between types and instances is difficult even for specialists: Try to be precise from the very beginning! assigned_to persnr entity year of assignment 1992 relationship name... Universität Bonn Foundations of IM 18

19 Roles One and the same entity type may participate in a relationship type more than once,, e.g.: mother descendent_of person daughter For a (syntactical( syntactical) distinction between the different forms of participation, special designators are used, called roles. Roles are used as labels of the lines connecting the resp. entity and relationship type. Foundations of IM 19

20 Extended Geo-DB: ER-diagram capital capital_of_country country 1 neighbour_country city country country 2 stadt_an_fluss city_in_country river_ through_ country region_ in_country river source river relationship type region source_of role entity type Foundations of IM 20

21 Relationship types and mathematical relations On the level of instances, a relation over the populations of the entity types involved is associated with each relationship type. E 1 R E 2 entities not involved in R Foundations of IM 21

22 Functional relationships In many cases, at most one entity on one side"" of a relationship type may be associated with a particular entity on the other side of the relationship,, e.g.: city country city_in_country Each Eachcity cityis isin in exactly one onecountry. In In each eachcountry, however, arbitrarily many cities may maybe besituated. Foundations of IM 22

23 Functional relationships (2) Mathematically, city_in_country is a function: city_in_country: city city country More exactly: :... a function from the population of city into the population of country. population(city (city) population(country (country) Foundations of IM 23

24 Functional relationships (3) In the ER-model model,, such restrictions of the admissible combinations can be expressed by means of so-called functionalities, annotations attached to the edges connecting entity and relationship types. There are four different kinds of binary relationships expressible by means of functionalities: 1 : : 1 1 : : N N : : 1 N : : M In this context,, N resp. M stands for arbitrary integer values 0. In the city_in_country' city_in_country'-example,, an N:1-relationship is appropriate: There is exactly one country per city, but arbitrarily many citites per country (N 0). city N 1 city_in_country country Foundations of IM 24

25 Functional relationships (4) Functionalities of type 1 : 1, 1 : N or N : 1 define partial functions where some of the instances of the types involved possibly are not related at all. city N 1 city_in_country country City without country! In the normal ER-model model,, total functions cannot be distinguished from partial ones in extensions of the model there are additional graphical means for ex- plicitly stating whether a function is partial or total. Foundations of IM 25

26 Functional relationships (5) In a 1 : 1-relationship1 each instance of one of the entity types involved is related to none or exactly one of the instances of the other entity type. An N : M-relationship can be considered the normal case" without restrictions on the number of participating entities. If no functionalities have been stated for a relationship type, then an implicit N : M functionality is assumed. Functionalities can be defined for relationships with more than two entities in- volved, too: E 1 N R M E 2 R: R: E 1 1 E 2 2 E E 3 Foundations of IM 26

27 Functional relationships (6) If in an n-ary relationship several edges are marked by '1', then the resp. relationship type represents several partial functions: E 1 N R 1 E 2 R (1) R (1) (1) : : E 1 1 E 2 2 E R (2) R (2) (2) : : E 1 1 E 3 3 E 2 2 E 3... and analogously: E 1 1 R 1 1 E 2 E 3 R (1) R (1) (1) : : E 1 1 E 2 2 E 3 3 R (2) R (2) (2) : : E 1 1 E 3 3 E 2 2 R (3) R (3) (3) : : E 2 2 E 3 3 E 1 1 Foundations of IM 27

28 Extended ER model: Generalization The concepts introduced so far have been contained in Chen s s original proposal throughout. Since then, however, various extensions have been proposed: Extended Entity-Relationship Model (EER-model) Most important extensions (as in object-oriented oriented models): Generalization This means: formation of subtypes of entity types sub-/supertype relationships (type hierarchy) inheritance of attributes and of participations"" in R-types Special graphical notation for generalization of E-types: is_a... Foundations of IM 28

29 Generalization (2) city capital_of region supertype name, area, inhabitants subtypes is_a country prime minister state governor Inheritance"" in this example means: Both subtypes inherit all attributes of the supertype, i.e., they own" these attributes without explicit definition. Both subtypes participate in the relationship type capital_of', which has been explicitly defined for the supertype only. Foundations of IM 29

30 Generalization (3) region is_a Generalization always means that the populations of the subtypes are subsets of the population of the supertype. country state population(region (region) This circumstance motivates the notion 'is_a' is_a'-relationship: population(country (country) "Every country is a region." Quantifier over instances! population(state (state) Foundations of IM 30

31 Generalization (4) In the example: special case disjoint generalization (Empty intersection of the populations) In general: This form of the 'is_a' is_a'-notation just means some form of subset formation,, i.e. overlapping, incomplete subdivision. Foundations of IM 31

32 Logical design: ER Relations Design documentation Logical structure on paper" Conceptual design Logical design Physical design ER ER model 1 st 1 st st step step Mapping Relational model Improvement Map MapER types systema- tically to to relations: From semantic concepts to to syntactic structures!! Foundations of IM 32

33 ER Relations: Mapping Entity types Mapping from ER model to relational model: in principle very easy: : per type one relation (table) in detail and for extensions: quite difficult Mapping of entity types: rather obvious type table name attribute E column name E A 1 A 2... A n A 1 A 2... A n Key attributes are mapped to primary key columns. Foundations of IM 33

34 ER Relations: Mapping Relationship types For relationship types: Use the same basic idea: one relation per type. but: How are participating entity types represented? city city_in_state state name inhabitants... since name area... Obvious solution as well: The participating entities are represented by means of the values of their primary key attributes (possibly after renaming). city_in_state city.name state.name since Foreign key Foundations of IM 34

35 ER Relations: Mapping Relationship types (2) In presence of special functionalities (1 : N, N : 1, 1 : 1 resp.), a separate relation- ship table is not necessary,, as the relationship information can be embedded into the table of the entity type on the N-side: city city_in_state N 1 state name inhabitants... since name area... Foreign key city city.name inhabitants... state.name since Foundations of IM 35

36 Relational representation of generalization hierarchies E 1 A 1, A 2,... How Howto to realize inheritance and and sub-/super type typerelationships relationally? is_a inheritance Relational model: does not know any inheritance! Inheritance thus has to be "simulated"". E 2 B 1, B 2,... Relational representation of a super type E 1 is obvious: E 1 A 1 A 2... Foundations of IM 36

37 Relational representation of generalization hierarchies (2) E 1 is_a A 1, A 2,... Inheritance E 1 A 1 A 2... a 11 a a 21 a inherited native" attributes E 2 B 1, B 2,... E 2 A 1 A 2... B 1 B 2... a 11 a b 11 b Obvious relational realization of a subtype: subtype relation E 2 owns native" and inherited attributes. But: Values of the inherited attributes of all E 2 -instances have to be (redundantly) repeated in the E 1 -relation in this case! Reason: Each E 2 -instance is an E 1 -instance, too! Foundations of IM 37

38 Relational representation of generalization hierarchies (3) E 1 is_a A 1, A 2,... Avoiding duplication: : Store only native" attributes (+ key for joining) ) in the subtype relation! inherited attributes E 2 B 1, B 2,... E 1 inheritance A 1 A 2... a 11 a a 21 a joint key native" attributes But Butin in this thiscase caserelation E 2 does 2 does no no longer contain all allattributes of of E 1 -entities 1!! E 2 A 1 B 1 B a 11 b 11 b 12 Foundations of IM 38

39 Relational representation of generalization hierarchies (4) way out: : E2-population is completely realized by means of a view joining the inherited and the native attributes. inherited attributes E 2 -global A 1 A 2... B 1 B 2... a 11 a b 11 b CREATE CREATE VIEW VIEW E2-global E2-global AS AS (SELECT (SELECT* * FROM FROM E1 E1 INNER INNER JOIN JOINE2-local ON ON E1.A1 E1.A1 = E2-local.A1) E2-local.A1) E 1 E 2 -local A 1 A 2... a 11 a a 21 a native" attributes A 1 B 1 B a 11 b 11 b 12 Foundations of IM 39

40 Relational representation of generalization hierarchies (5) 3 rd rd alternative (also free of redundancies and using a view): Distribute values of the inherited attributes to different relations super types are reconstructed via views. E 1 -local E 1 -global A 1 A 2... a 11 a a 21 a A 1 A 2... a 21 a CREATE CREATE VIEW VIEW E1-global E1-global AS AS ( ( TABLE TABLE E1-local E1-local )) UNION UNION (SELECT (SELECT A 1, 1, A 2, 2, FROM FROM E2 E2 )) E 2 π inherited native" attributes A 1 A 2... B 1 B 2... a 11 a b 11 b Foundations of IM 40

41 Relational representation of generalization hierarchies (6) Which of of the thethree threealternatives is is the the best" best"? 1. Relations E 1 and E 2, no views: + short access time (without any join of tables) high requirements for space (due to redundant storage) 2. Relations E 1 and E 2 -local, view E 2 -global (JOIN): + Only key attribute values are stored redundantly. Access to E 2 -attributes is slower (due to join). 3. Relations E 2 and E 1 -local, view E 1 -global (PROJECT-UNION): + No duplication of any attribute values. Access to E 1 -attributes is slower (due to projection and union) ). Foundations of IM 41

42 Generalization and updates E 1 is_a E 2 A 1, A 2,... B 1, B 2,... What happens if ifan an E 2 -entity 2 is isdeleted? relational variant 1 (inherited( attributes duplicated): Deletion from both relations is necessary. relational variant 2 (inherited( and native A. separated): Deletion from both relations is necessary. relational variant 3 (E 2 -attributes only in one relation): no propagation of deletions required In In variants 1 and and 2: 2: referential integrity constraints with withdelete cascade is isrequired. For insertions and modifications: Changes in several relations may be necessary, too (depending on the chosen strategy). Deletion of instances of the super type E 1 : Cascading deletion if the resp. instance is an E 2 -instance, too (again referential integrity). Foundations of IM 42

43 Relationships and referential integrity Each relationship type induces FOREIGN KEY-constraints as well: With N : M-functionality: river_through_state river N M state CREATE CREATE TABLE TABLE river_through_state river_through_state ( ( River River String String REFERENCES REFERENCESriver, river, State State String String REFERENCES REFERENCESstate state )) With N : 1-functionality: 1 city N city_in in_state 1 state CREATE CREATE TABLE TABLE city city ( (....,, State State String String REFERENCES REFERENCESstate state )) Foundations of IM 43

44 Functionalities as constraints But: Uniqueness of the state in the city_in in_state-relationship has not yet been expressed! An additional CHECK-constraint is required contraining the number of state instances: city city_in in_state N 1 state CREATE CREATE TABLE TABLE city city ( (....,, CHECK CHECK COUNT COUNT (SELECT (SELECT State State FROM FROM city citys WHERE WHERE S.Name S.Name = Name) Name) =< =< 11 Implicit universal quantifier ranging over each city row! Foundations of IM 44

45 ER Relations (2) Design documentation Logical structure on paper" Conceptual design Logical design Physical design ER ER model Mapping Relational model Improvement 2 nd nd step step (after (afterreaching relations): Improve design by by fine tuning the the structure of of tables Foundations of IM 45

46 Redundancies due to bad design Example of bad design (remaining after mapping from ER level): City_in_ City_in_state and capital_of have been placed into a single table. City Bonn Köln Essen... Mainz Trier... State Capital NW NW NW RP RP Düsseldorf Düsseldorf Düsseldorf Mainz Mainz Redundantly stored information: Düsseldorf is isthe thecapital of of North Rhine-Westphalia. Obviously one topic (Which city is the capital of...?) has been combined with another topic (In which state is a certain city situated?) in such an unlucky manner that considerable redundancies occur, resulting in waste of space. What does does a a topic mean? Foundations of IM 46

47 Anomalies resulting from redundancies An immediate consequence of such cases of storing multiple topics in one table is the occurrence of so-called anomalies when updating such tables: Assume Köln (as( largest city in NW) replaces Düsseldorf as capital: One fact changes, but multiple updates have to be made. City Bonn Köln Essen... Mainz Trier... State Capital NW NW NW RP RP Düsseldorf Düsseldorf Düsseldorf Mainz Mainz Analoguos anomalies may happen due to insertions and deletions: An instance of topic 1 disappears, as soon as it is no longer associated with any instance of topic 2. A new instance of topic 1 can only be inserted, if it is combined with an instance of topic 2 (or( null values are used). Foundations of IM 47

48 Decompositions avoid redundancies and anomalies How Howto to prevent such such defects (anomalies, redundancies) )? In the example, there is a simple remedy: Separate the two topics into different relations! City Bonn Köln Essen... Mainz Trier... State Capital NW NW NW RP RP Düsseldorf Düsseldorf Düsseldorf Mainz Mainz No redundancy,, no anomaly! Decomposition City Bonn Köln Neuss... State NW NW NW State Capital NW RP... Düsseldorf Mainz Foundations of IM 48

49 Functional dependencies and decompositions Already discovered by Codd before 1970: Functional relationships between attributes are of help for finding meaningful decompositions and for avoiding reduncancies! Resulting from this observation, Codd developed an elaborate theory of relational normal forms. Prerequisite: : Designers identify such functional relationships during schema design (quite( similar to identifying functionalities in the ER model) ) and express them as special integrity constraints. Functional dependency (short:: FD) Principle of functional dependency: Let A and B be attributes of a relation R. B depends functionally on A, A if in each state of R each A-value always occurs in combination with the same, uniquely determined B-value. symbolic notation: A B Foundations of IM 49

50 FDs in the example Each city lies in exactly one state: City State Each state has exactly one capital: State Capital But also: If a city is a capital then it is the capital of exactly one state: Capital State Each city is associated with exactly one capital (namely the capital of its state): City Capital City Bonn Köln Essen... Mainz Trier... State Capital NW NW NW RP RP Düsseldorf Düsseldorf Düsseldorf Mainz Mainz Decomposition separates FDs: City State State Capital One FD seems to be lost, however: : City Capital Foundations of IM 50

51 "Codd's thesis" Thesis (claim( claim) on which the normalization theory of Codd is based: Attributes connected via viaan anfd FDrepresent semantically significant topics of of the theapplication domain. That is: Every FD identifies a topic thus separating topics means separating FDs. But: Not every such topic is necessarily represented by an FD. Moreover: : FD-connection is a sufficient, but not a necessary criterion for the existence of a topic. Basic idea of Codd s approach to normalization of relations: Decompose relations in such a way that normally" each FD has a compo- nent relation of its own. But try to identify exceptions where several FDs may coexist in one and the same relation! Foundations of IM 51

52 Transitive FDs and Armstrong s axioms There are FDs which are derivable from other FDs, already known.. An important example are so-called transitive FDs: α β is a transitive FD if there is an attribute set γ, such that α γ and γ β are both FDs, but not γ α. Every such transitive case leads to a (new( new) functional dependency. There are two other such inference rules for FDs, called the Armstrong axioms (as they have been discovered by the Canadian scientist W. Armstrong). ββ α α αα β β αα β β ααγ γ ββγ γ Every subset depends on its superset. Augmentation on both sides. Not to be found in the literature, but quite useful: : Special notion for FDs which are not transitive FDs: α β is a direct FD if there is no attribute set γ, such that α γ and γ β are both FDs, but not γ α. Foundations of IM 52

53 Normal forms Properly determining FDs and investigating their properties is the basis for each meaningful decomposition of relations into components free of redundancies. Codd's recepy (in (in short shortfrom): Redundancies can canbe besafely avoided if iffds FDsalways originate from from candidate keys keysof of a relation. Codd defined various degrees of FD separation, called normal forms the process of transforming a given schema into relations all of which exhibit a given normal form is called normalization. The most important normal form is the third normal form (short: 3NF) defined as follows: A relation is isin in 3 rd rd normal form form Each Eachnon-key attribute functionally depends directly on on each eachcandidate key keyof of the therelation.. There are various other normal forms (1NF, 2NF, 4NF and others). Foundations of IM 53

54 Normalization in the example schema Our example schema from the geographic domain originally was not in 3NF, as it still contains a transitive dependency pointing from a candidate key (City) to a non-key attribute (Capital): (R, ) City 3NF Bonn Köln Essen... State NW NW NW Capital Düsseldorf Düsseldorf Düsseldorf (R, ) (R, ) City State State Capital 3NF 3NF After decomposition, however, each of the resulting component schemas is in 3NF! Such a decomposition will always be possible. The lost dependency City Capital can be reconstructed by means of the transitivity axiom of Armstrong. Foundations of IM 54

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model The entity-relationship (E-R) model is a a data model in which information stored

More information

DATABASE NORMALIZATION

DATABASE NORMALIZATION DATABASE NORMALIZATION Normalization: process of efficiently organizing data in the DB. RELATIONS (attributes grouped together) Accurate representation of data, relationships and constraints. Goal: - Eliminate

More information

2. Conceptual Modeling using the Entity-Relationship Model

2. Conceptual Modeling using the Entity-Relationship Model ECS-165A WQ 11 15 Contents 2. Conceptual Modeling using the Entity-Relationship Model Basic concepts: entities and entity types, attributes and keys, relationships and relationship types Entity-Relationship

More information

2. Basic Relational Data Model

2. Basic Relational Data Model 2. Basic Relational Data Model 2.1 Introduction Basic concepts of information models, their realisation in databases comprising data objects and object relationships, and their management by DBMS s that

More information

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys

Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys Database Design Overview Conceptual Design. The Entity-Relationship (ER) Model CS430/630 Lecture 12 Conceptual design The Entity-Relationship (ER) Model, UML High-level, close to human thinking Semantic

More information

Normalization in Database Design

Normalization in Database Design in Database Design Marek Rychly mrychly@strathmore.edu Strathmore University, @ilabafrica & Brno University of Technology, Faculty of Information Technology Advanced Databases and Enterprise Systems 14

More information

CS 377 Database Systems. Database Design Theory and Normalization. Li Xiong Department of Mathematics and Computer Science Emory University

CS 377 Database Systems. Database Design Theory and Normalization. Li Xiong Department of Mathematics and Computer Science Emory University CS 377 Database Systems Database Design Theory and Normalization Li Xiong Department of Mathematics and Computer Science Emory University 1 Relational database design So far Conceptual database design

More information

Conceptual Design Using the Entity-Relationship (ER) Model

Conceptual Design Using the Entity-Relationship (ER) Model Conceptual Design Using the Entity-Relationship (ER) Model Module 5, Lectures 1 and 2 Database Management Systems, R. Ramakrishnan 1 Overview of Database Design Conceptual design: (ER Model is used at

More information

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations

Bridge from Entity Relationship modeling to creating SQL databases, tables, & relations 1 Topics for this week: 1. Good Design 2. Functional Dependencies 3. Normalization Readings for this week: 1. E&N, Ch. 10.1-10.6; 12.2 2. Quickstart, Ch. 3 3. Complete the tutorial at http://sqlcourse2.com/

More information

RELATIONAL DATABASE DESIGN

RELATIONAL DATABASE DESIGN RELATIONAL DATABASE DESIGN g Good database design - Avoiding anomalies g Functional Dependencies g Normalization & Decomposition Using Functional Dependencies g 1NF - Atomic Domains and First Normal Form

More information

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Chapter 2: Entity-Relationship Model. Entity Sets.  Example: specific person, company, event, plant Chapter 2: Entity-Relationship Model! Entity Sets! Relationship Sets! Design Issues! Mapping Constraints! Keys! E-R Diagram! Extended E-R Features! Design of an E-R Database Schema! Reduction of an E-R

More information

Chapter 10. Functional Dependencies and Normalization for Relational Databases

Chapter 10. Functional Dependencies and Normalization for Relational Databases Chapter 10 Functional Dependencies and Normalization for Relational Databases Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1Semantics of the Relation Attributes 1.2 Redundant

More information

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd.

Databases Model the Real World. The Entity- Relationship Model. Conceptual Design. Steps in Database Design. ER Model Basics. ER Model Basics (Contd. The Entity- Relationship Model R &G - Chapter 2 A relationship, I think, is like a shark, you know? It has to constantly move forward or it dies. And I think what we got on our hands is a dead shark. Woody

More information

Database Design and Normalization

Database Design and Normalization Database Design and Normalization CPS352: Database Systems Simon Miner Gordon College Last Revised: 9/27/12 Agenda Check-in Functional Dependencies (continued) Design Project E-R Diagram Presentations

More information

IT2305 Database Systems I (Compulsory)

IT2305 Database Systems I (Compulsory) Database Systems I (Compulsory) INTRODUCTION This is one of the 4 modules designed for Semester 2 of Bachelor of Information Technology Degree program. CREDITS: 04 LEARNING OUTCOMES On completion of this

More information

The Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1

The Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1 The Relational Model Ramakrishnan&Gehrke, Chapter 3 CS4320 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. Legacy systems in older models

More information

Chapter 2: Entity-Relationship Model. E-R R Diagrams

Chapter 2: Entity-Relationship Model. E-R R Diagrams Chapter 2: Entity-Relationship Model What s the use of the E-R model? Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E-R Diagram Extended E-R Features Design of an E-R Database Schema

More information

Schema Refinement, Functional Dependencies, Normalization

Schema Refinement, Functional Dependencies, Normalization Schema Refinement, Functional Dependencies, Normalization MSCI 346: Database Systems Güneş Aluç, University of Waterloo Spring 2015 MSCI 346: Database Systems Chapter 19 1 / 42 Outline 1 Introduction Design

More information

IT2304: Database Systems 1 (DBS 1)

IT2304: Database Systems 1 (DBS 1) : Database Systems 1 (DBS 1) (Compulsory) 1. OUTLINE OF SYLLABUS Topic Minimum number of hours Introduction to DBMS 07 Relational Data Model 03 Data manipulation using Relational Algebra 06 Data manipulation

More information

Data Modeling. Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4

Data Modeling. Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4 Data Modeling Database Systems: The Complete Book Ch. 4.1-4.5, 7.1-7.4 Data Modeling Schema: The structure of the data Structured Data: Relational, XML-DTD, etc Unstructured Data: CSV, JSON But where does

More information

Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases

Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 15 Outline Informal Design Guidelines

More information

Database Design Process. Databases - Entity-Relationship Modelling. Requirements Analysis. Database Design

Database Design Process. Databases - Entity-Relationship Modelling. Requirements Analysis. Database Design Process Databases - Entity-Relationship Modelling Ramakrishnan & Gehrke identify six main steps in designing a database Requirements Analysis Conceptual Design Logical Design Schema Refinement Physical

More information

A brief overview of developing a conceptual data model as the first step in creating a relational database.

A brief overview of developing a conceptual data model as the first step in creating a relational database. Data Modeling Windows Enterprise Support Database Services provides the following documentation about relational database design, the relational database model, and relational database software. Introduction

More information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model 221 After completing this chapter, you should be able to explain the three phases of database design, Why are multiple phases useful? evaluate the significance of the Entity-Relationship

More information

The process of database development. Logical model: relational DBMS. Relation

The process of database development. Logical model: relational DBMS. Relation The process of database development Reality (Universe of Discourse) Relational Databases and SQL Basic Concepts The 3rd normal form Structured Query Language (SQL) Conceptual model (e.g. Entity-Relationship

More information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3

The Relational Model. Why Study the Relational Model? Relational Database: Definitions. Chapter 3 The Relational Model Chapter 3 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase,

More information

Outline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst

Outline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst Outline Data Modeling Yanlei Diao UMass Amherst v Conceptual Design: ER Model v Relational Model v Logical Design: from ER to Relational Slides Courtesy of R. Ramakrishnan and J. Gehrke 1 2 Conceptual

More information

Requirement Analysis & Conceptual Database Design. Problem analysis Entity Relationship notation Integrity constraints Generalization

Requirement Analysis & Conceptual Database Design. Problem analysis Entity Relationship notation Integrity constraints Generalization Requirement Analysis & Conceptual Database Design Problem analysis Entity Relationship notation Integrity constraints Generalization Introduction: Lifecycle Requirement analysis -> Text Conceptual Design

More information

BCA. Database Management System

BCA. Database Management System BCA IV Sem Database Management System Multiple choice questions 1. A Database Management System (DBMS) is A. Collection of interrelated data B. Collection of programs to access data C. Collection of data

More information

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise

Database Design. Database Design I: The Entity-Relationship Model. Entity Type (con t) Chapter 4. Entity: an object that is involved in the enterprise Database Design Database Design I: The Entity-Relationship Model Chapter 4 Goal: specification of database schema Methodology: Use E-R R model to get a high-level graphical view of essential components

More information

SQL DDL. DBS Database Systems Designing Relational Databases. Inclusion Constraints. Key Constraints

SQL DDL. DBS Database Systems Designing Relational Databases. Inclusion Constraints. Key Constraints DBS Database Systems Designing Relational Databases Peter Buneman 12 October 2010 SQL DDL In its simplest use, SQL s Data Definition Language (DDL) provides a name and a type for each column of a table.

More information

Database Management System

Database Management System UNIT -6 Database Design Informal Design Guidelines for Relation Schemas; Functional Dependencies; Normal Forms Based on Primary Keys; General Definitions of Second and Third Normal Forms; Boyce-Codd Normal

More information

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB

Database Design. Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB Marta Jakubowska-Sobczak IT/ADC based on slides prepared by Paula Figueiredo, IT/DB Outline Database concepts Conceptual Design Logical Design Communicating with the RDBMS 2 Some concepts Database: an

More information

Logical Schema Design: The Relational Data Model

Logical Schema Design: The Relational Data Model Logical Schema Design: The Relational Data Model Basics of the Relational Model From Conceptual to Logical Schema Logical Schema Design Select data model Hierarchical data model: hierarchies of record

More information

Functional Dependency and Normalization for Relational Databases

Functional Dependency and Normalization for Relational Databases Functional Dependency and Normalization for Relational Databases Introduction: Relational database design ultimately produces a set of relations. The implicit goals of the design activity are: information

More information

Modern Systems Analysis and Design

Modern Systems Analysis and Design Modern Systems Analysis and Design Prof. David Gadish Structuring System Data Requirements Learning Objectives Concisely define each of the following key data modeling terms: entity type, attribute, multivalued

More information

Lesson 8: Introduction to Databases E-R Data Modeling

Lesson 8: Introduction to Databases E-R Data Modeling Lesson 8: Introduction to Databases E-R Data Modeling Contents Introduction to Databases Abstraction, Schemas, and Views Data Models Database Management System (DBMS) Components Entity Relationship Data

More information

Lecture 6. SQL, Logical DB Design

Lecture 6. SQL, Logical DB Design Lecture 6 SQL, Logical DB Design Relational Query Languages A major strength of the relational model: supports simple, powerful querying of data. Queries can be written intuitively, and the DBMS is responsible

More information

Database Design. Goal: specification of database schema Methodology: E-R Model is viewed as a set of

Database Design. Goal: specification of database schema Methodology: E-R Model is viewed as a set of Database Design Goal: specification of database schema Methodology: Use E-R model to get a high-level graphical view of essential components of the model and how they are related Convert E-R diagram to

More information

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to:

14 Databases. Source: Foundations of Computer Science Cengage Learning. Objectives After studying this chapter, the student should be able to: 14 Databases 14.1 Source: Foundations of Computer Science Cengage Learning Objectives After studying this chapter, the student should be able to: Define a database and a database management system (DBMS)

More information

7.1 The Information system

7.1 The Information system Chapter 7. Database Planning, Design and Administration Last few decades have seen proliferation of software applications, many requiring constant maintenance involving: correcting faults, implementing

More information

Entity-Relationship Model

Entity-Relationship Model UNIT -2 Entity-Relationship Model Introduction to ER Model ER model is represents real world situations using concepts, which are commonly used by people. It allows defining a representation of the real

More information

Conceptual Design: Entity Relationship Models. Objectives. Overview

Conceptual Design: Entity Relationship Models. Objectives. Overview Conceptual Design: Entity Relationship Models Craig Van Slyke, University of Central Florida cvanslyke@bus.ucf.edu John Day, Ohio University Objectives Define terms related to entity relationship modeling,

More information

Relational Database Design

Relational Database Design Relational Database Design To generate a set of relation schemas that allows - to store information without unnecessary redundancy - to retrieve desired information easily Approach - design schema in appropriate

More information

Normalization. Normalization. Normalization. Data Redundancy

Normalization. Normalization. Normalization. Data Redundancy Normalization Normalization o Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data, its relationships, and constraints.

More information

Data Modeling: Part 1. Entity Relationship (ER) Model

Data Modeling: Part 1. Entity Relationship (ER) Model Data Modeling: Part 1 Entity Relationship (ER) Model MBA 8473 1 Cognitive Objectives (Module 2) 32. Explain the three-step process of data-driven information system (IS) development 33. Examine the purpose

More information

Theory of Relational Database Design and Normalization

Theory of Relational Database Design and Normalization Theory of Relational Database Design and Normalization (Based on Chapter 14 and some part of Chapter 15 in Fundamentals of Database Systems by Elmasri and Navathe, Ed. 3) 1 Informal Design Guidelines for

More information

DATABASE MANAGEMENT SYSTEMS. Question Bank:

DATABASE MANAGEMENT SYSTEMS. Question Bank: DATABASE MANAGEMENT SYSTEMS Question Bank: UNIT 1 1. Define Database? 2. What is a DBMS? 3. What is the need for database systems? 4. Define tupule? 5. What are the responsibilities of DBA? 6. Define schema?

More information

Normalization in OODB Design

Normalization in OODB Design Normalization in OODB Design Byung S. Lee Graduate Programs in Software University of St. Thomas St. Paul, Minnesota bslee@stthomas.edu Abstract When we design an object-oriented database schema, we need

More information

Foundations of Information Management

Foundations of Information Management Foundations of Information Management - WS 2012/13 - Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Data & Databases Data: Simple information Database:

More information

Chapter 2: Entity-Relationship Model

Chapter 2: Entity-Relationship Model Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E R Diagram Extended E-R Features Design of an E-R Database Schema Reduction of an E-R Schema to

More information

Chapter 8. Database Design II: Relational Normalization Theory

Chapter 8. Database Design II: Relational Normalization Theory Chapter 8 Database Design II: Relational Normalization Theory The E-R approach is a good way to start dealing with the complexity of modeling a real-world enterprise. However, it is only a set of guidelines

More information

Chapter 7: Relational Database Design

Chapter 7: Relational Database Design Chapter 7: Relational Database Design Database System Concepts, 5th Ed. See www.db book.com for conditions on re use Chapter 7: Relational Database Design Features of Good Relational Design Atomic Domains

More information

Fundamentals of Database System

Fundamentals of Database System Fundamentals of Database System Chapter 4 Normalization Fundamentals of Database Systems (Chapter 4) Page 1 Introduction To Normalization In general, the goal of a relational database design is to generate

More information

3. Relational Model and Relational Algebra

3. Relational Model and Relational Algebra ECS-165A WQ 11 36 3. Relational Model and Relational Algebra Contents Fundamental Concepts of the Relational Model Integrity Constraints Translation ER schema Relational Database Schema Relational Algebra

More information

CS2Bh: Current Technologies. Introduction to XML and Relational Databases. The Relational Model. The relational model

CS2Bh: Current Technologies. Introduction to XML and Relational Databases. The Relational Model. The relational model CS2Bh: Current Technologies Introduction to XML and Relational Databases Spring 2005 The Relational Model CS2 Spring 2005 (LN6) 1 The relational model Proposed by Codd in 1970. It is the dominant data

More information

Database Design and Normal Forms

Database Design and Normal Forms Database Design and Normal Forms Database Design coming up with a good schema is very important How do we characterize the goodness of a schema? If two or more alternative schemas are available how do

More information

How To Write A Diagram

How To Write A Diagram Data Model ing Essentials Third Edition Graeme C. Simsion and Graham C. Witt MORGAN KAUFMANN PUBLISHERS AN IMPRINT OF ELSEVIER AMSTERDAM BOSTON LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE

More information

Fundamentals of Database Design

Fundamentals of Database Design Fundamentals of Database Design Zornitsa Zaharieva CERN Data Management Section - Controls Group Accelerators and Beams Department /AB-CO-DM/ 23-FEB-2005 Contents : Introduction to Databases : Main Database

More information

Databases -Normalization III. (N Spadaccini 2010 and W Liu 2012) Databases - Normalization III 1 / 31

Databases -Normalization III. (N Spadaccini 2010 and W Liu 2012) Databases - Normalization III 1 / 31 Databases -Normalization III (N Spadaccini 2010 and W Liu 2012) Databases - Normalization III 1 / 31 This lecture This lecture describes 3rd normal form. (N Spadaccini 2010 and W Liu 2012) Databases -

More information

Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES

Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES 1 Chapter 5: FUNCTIONAL DEPENDENCIES AND NORMALIZATION FOR RELATIONAL DATABASES INFORMAL DESIGN GUIDELINES FOR RELATION SCHEMAS We discuss four informal measures of quality for relation schema design in

More information

Week 11: Normal Forms. Logical Database Design. Normal Forms and Normalization. Examples of Redundancy

Week 11: Normal Forms. Logical Database Design. Normal Forms and Normalization. Examples of Redundancy Week 11: Normal Forms Database Design Database Redundancies and Anomalies Functional Dependencies Entailment, Closure and Equivalence Lossless Decompositions The Third Normal Form (3NF) The Boyce-Codd

More information

COSC344 Database Theory and Applications. Lecture 9 Normalisation. COSC344 Lecture 9 1

COSC344 Database Theory and Applications. Lecture 9 Normalisation. COSC344 Lecture 9 1 COSC344 Database Theory and Applications Lecture 9 Normalisation COSC344 Lecture 9 1 Overview Last Lecture Functional Dependencies This Lecture Normalisation Introduction 1NF 2NF 3NF BCNF Source: Section

More information

Chapter 10 Functional Dependencies and Normalization for Relational Databases

Chapter 10 Functional Dependencies and Normalization for Relational Databases Chapter 10 Functional Dependencies and Normalization for Relational Databases Copyright 2004 Pearson Education, Inc. Chapter Outline 1 Informal Design Guidelines for Relational Databases 1.1Semantics of

More information

The Relational Model. Why Study the Relational Model? Relational Database: Definitions

The Relational Model. Why Study the Relational Model? Relational Database: Definitions The Relational Model Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Microsoft, Oracle, Sybase, etc. Legacy systems in

More information

Tutorial on Relational Database Design

Tutorial on Relational Database Design Tutorial on Relational Database Design Introduction Relational database was proposed by Edgar Codd (of IBM Research) around 1969. It has since become the dominant database model for commercial applications

More information

CSC 742 Database Management Systems

CSC 742 Database Management Systems CSC 742 Database Management Systems Topic #4: Data Modeling Spring 2002 CSC 742: DBMS by Dr. Peng Ning 1 Phases of Database Design Requirement Collection/Analysis Functional Requirements Functional Analysis

More information

Data Modeling Basics

Data Modeling Basics Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy

More information

www.gr8ambitionz.com

www.gr8ambitionz.com Data Base Management Systems (DBMS) Study Material (Objective Type questions with Answers) Shared by Akhil Arora Powered by www. your A to Z competitive exam guide Database Objective type questions Q.1

More information

Relational Database Design: FD s & BCNF

Relational Database Design: FD s & BCNF CS145 Lecture Notes #5 Relational Database Design: FD s & BCNF Motivation Automatic translation from E/R or ODL may not produce the best relational design possible Sometimes database designers like to

More information

Lecture Notes INFORMATION RESOURCES

Lecture Notes INFORMATION RESOURCES Vilnius Gediminas Technical University Jelena Mamčenko Lecture Notes on INFORMATION RESOURCES Part I Introduction to Dta Modeling and MSAccess Code FMITB02004 Course title Information Resourses Course

More information

1 Class Diagrams and Entity Relationship Diagrams (ERD)

1 Class Diagrams and Entity Relationship Diagrams (ERD) 1 Class Diagrams and Entity Relationship Diagrams (ERD) Class diagrams and ERDs both model the structure of a system. Class diagrams represent the dynamic aspects of a system: both the structural and behavioural

More information

LOGICAL DATABASE DESIGN

LOGICAL DATABASE DESIGN MODULE 8 LOGICAL DATABASE DESIGN OBJECTIVE QUESTIONS There are 4 alternative answers to each question. One of them is correct. Pick the correct answer. Do not guess. A key is given at the end of the module

More information

IV. The (Extended) Entity-Relationship Model

IV. The (Extended) Entity-Relationship Model IV. The (Extended) Entity-Relationship Model The Extended Entity-Relationship (EER) Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of EER Diagrams

More information

Chapter 8 The Enhanced Entity- Relationship (EER) Model

Chapter 8 The Enhanced Entity- Relationship (EER) Model Chapter 8 The Enhanced Entity- Relationship (EER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 Outline Subclasses, Superclasses, and Inheritance Specialization

More information

The Relational Model. Why Study the Relational Model?

The Relational Model. Why Study the Relational Model? The Relational Model Chapter 3 Instructor: Vladimir Zadorozhny vladimir@sis.pitt.edu Information Science Program School of Information Sciences, University of Pittsburgh 1 Why Study the Relational Model?

More information

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer About the Tutorial Database Management System or DBMS in short refers to the technology of storing and retrieving users data with utmost efficiency along with appropriate security measures. DBMS allows

More information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model Overview of Database Design Requirements analysis Conceptual design data model Logical design Schema refinement: Normalization Physical tuning Conceptual Design Entities Conceptual

More information

The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and

The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and CMPT-354-Han-95.3 Lecture Notes September 20, 1995 Chapter 2 The Entity-Relationship Model The E-R èentity-relationshipè data model views the real world as a set of basic objects èentitiesè and relationships

More information

Normal forms and normalization

Normal forms and normalization Normal forms and normalization An example of normalization using normal forms We assume we have an enterprise that buys products from different supplying companies, and we would like to keep track of our

More information

How To Find Out What A Key Is In A Database Engine

How To Find Out What A Key Is In A Database Engine Database design theory, Part I Functional dependencies Introduction As we saw in the last segment, designing a good database is a non trivial matter. The E/R model gives a useful rapid prototyping tool,

More information

My Favorite Issues in Data Warehouse Modeling

My Favorite Issues in Data Warehouse Modeling University of Münster My Favorite Issues in Data Warehouse Modeling Jens Lechtenbörger University of Münster & ERCIS, Germany http://dbms.uni-muenster.de Context Data Warehouse (DW) modeling ETL design

More information

Lecture 2 Normalization

Lecture 2 Normalization MIT 533 ระบบฐานข อม ล 2 Lecture 2 Normalization Walailuk University Lecture 2: Normalization 1 Objectives The purpose of normalization The identification of various types of update anomalies The concept

More information

Functional Dependencies and Normalization

Functional Dependencies and Normalization Functional Dependencies and Normalization 5DV119 Introduction to Database Management Umeå University Department of Computing Science Stephen J. Hegner hegner@cs.umu.se http://www.cs.umu.se/~hegner Functional

More information

CS143 Notes: Normalization Theory

CS143 Notes: Normalization Theory CS143 Notes: Normalization Theory Book Chapters (4th) Chapters 7.1-6, 7.8, 7.10 (5th) Chapters 7.1-6, 7.8 (6th) Chapters 8.1-6, 8.8 INTRODUCTION Main question How do we design good tables for a relational

More information

Relational Database Basics Review

Relational Database Basics Review Relational Database Basics Review IT 4153 Advanced Database J.G. Zheng Spring 2012 Overview Database approach Database system Relational model Database development 2 File Processing Approaches Based on

More information

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model

Chapter 3. Data Modeling Using the Entity-Relationship (ER) Model Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model Chapter Outline Overview of Database Design Process Example Database Application (COMPANY) ER Model Concepts Entities and Attributes Entity

More information

Normalization of Database

Normalization of Database Normalization of Database UNIT-4 Database Normalisation is a technique of organizing the data in the database. Normalization is a systematic approach of decomposing tables to eliminate data redundancy

More information

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University Data Analysis 1 SET08104 Database Systems Copyright @ Napier University Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship?

More information

C# Cname Ccity.. P1# Date1 Qnt1 P2# Date2 P9# Date9 1 Codd London.. 1 21.01 20 2 23.01 2 Martin Paris.. 1 26.10 25 3 Deen London.. 2 29.

C# Cname Ccity.. P1# Date1 Qnt1 P2# Date2 P9# Date9 1 Codd London.. 1 21.01 20 2 23.01 2 Martin Paris.. 1 26.10 25 3 Deen London.. 2 29. 4. Normalisation 4.1 Introduction Suppose we are now given the task of designing and creating a database. How do we produce a good design? What relations should we have in the database? What attributes

More information

Databases and BigData

Databases and BigData Eduardo Cunha de Almeida eduardo.almeida@uni.lu Outline of the course Introduction Database Systems (E. Almeida) Distributed Hash Tables and P2P (C. Cassagnes) NewSQL (D. Kim and J. Meira) NoSQL (D. Kim)

More information

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E)

THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) THE ENTITY- RELATIONSHIP (ER) MODEL CHAPTER 7 (6/E) CHAPTER 3 (5/E) 2 LECTURE OUTLINE Using High-Level, Conceptual Data Models for Database Design Entity-Relationship (ER) model Popular high-level conceptual

More information

6.830 Lecture 3 9.16.2015 PS1 Due Next Time (Tuesday!) Lab 1 Out today start early! Relational Model Continued, and Schema Design and Normalization

6.830 Lecture 3 9.16.2015 PS1 Due Next Time (Tuesday!) Lab 1 Out today start early! Relational Model Continued, and Schema Design and Normalization 6.830 Lecture 3 9.16.2015 PS1 Due Next Time (Tuesday!) Lab 1 Out today start early! Relational Model Continued, and Schema Design and Normalization Animals(name,age,species,cageno,keptby,feedtime) Keeper(id,name)

More information

SQL Server. 1. What is RDBMS?

SQL Server. 1. What is RDBMS? SQL Server 1. What is RDBMS? Relational Data Base Management Systems (RDBMS) are database management systems that maintain data records and indices in tables. Relationships may be created and maintained

More information

Review: Participation Constraints

Review: Participation Constraints Review: Participation Constraints Does every department have a manager? If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial). Every did

More information

Normalization. Reduces the liklihood of anomolies

Normalization. Reduces the liklihood of anomolies Normalization Normalization Tables are important, but properly designing them is even more important so the DBMS can do its job Normalization the process for evaluating and correcting table structures

More information

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University Data Analysis 1 Unit 2.1 Data Analysis 1 - V2.0 1 Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship? Entities, attributes,

More information

The Entity-Relationship Model

The Entity-Relationship Model The Entity-Relationship Model Chapter 2 Slides modified by Rasmus Pagh for Database Systems, Fall 2006 IT University of Copenhagen Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Today

More information

Foundations of Information Management

Foundations of Information Management Foundations of Information Management - WS 2009/10 Juniorprofessor Alexander Markowetz Bonn Aachen International Center for Information Technology (B-IT) Alexander Markowetz Born 1976 in Brussels, Belgium

More information

DATABASE INTRODUCTION

DATABASE INTRODUCTION Introduction The history of database system research is one of exceptional productivity and startling economic impact. We have learnt that from the days of file-based systems there are better ways to handle

More information