Context The Relational Data Model in a nutshell. 3.1 Logical schema design. Keep It simple, students KISS -

Size: px

Start display at page:

Download "Context The Relational Data Model in a nutshell. 3.1 Logical schema design. Keep It simple, students KISS -"

Hope Copeland
5 years ago
Views:

1 3. Schema Design: Logical Design using the Relational Data Model 3.1 Logical Schema Design The Relational Data Model in a nutshell Keys, candidate keys and more 3.2 From onceptual to Logical Schema: Mapping ER to RDM Relationships to tables onsolidation Mapping generalization hierarchies and more Enforcing constraints 3.3 Triggers 3.4 Data types 3.5 Metadata Management Kemper/ Eickler: chap , Elmasri / Navathe: chap. 9 SQL/DDL: Melton/Simon: chap 2, 3.3, 4 System documentation (e.g. Postgres, Oracle, MySQL, see references) ontext Requirements analysis onceptual Design Schema design - logical ( create tables ) Schema design -physical ( create access path ) Loading, administration, tuning, maintenance, reorganization System analyst D designer pplication programmer pplication programmer D administrator D administrator 04-DS-ER-RDM Logical schema design Logical Schema design is the transformation of the conceptual schema (e.g. ERM) into the logical schema (e.g RDM) Easy: lgorithmic transformation using development tools (Oracle, Visio, DDesigner, several Eclipse plugins, Main concerns: - how to map relationships to tables - how to represent integrity constraints The Relational Data Model in a nutshell The Relational Data Model Simplicity and formal rigor as the guiding principle KISS - asically: an algebra of tables Keep It simple, students Table: data structure with a fixed number of d columns and an arbitray number of rows. 04-DS-ER-RDM-3 04-DS-ER-RDM-4 asics relation (table) attribute tuple Relation schema (simplified notation omitting types): Student(f,, , matrno) arla Müller Katz Maus Student mueller@... katz@... piep@... matrno SQL Data Definition Lanuage RETE TLE Student( f VRHR (20), VRHR (30) NOT NULL, VRHR (40), matrno INTEGER ) 04-DS-ER-RDM-5 Properties of the RDM No duplicate rows R is a set No tuple order ttributes have a primitive type, no constructed type single-valued ttributes may have no value (NULL value) Integrity constraints must hold for all states of the D over time ("invariant") Unique s in the relation and the D space using dot-notation: R.a, db.s.b Database relations are time variant update, insertion, deletion of tuples most DS today allow constructed and multivalued types 04-DS-ER-RDM-6 1

2 Keys and candidate keys Def.: key of R(a1,,an) is a subset of its its attributes, which uniquely determines the tuples (= rows) of R and is minimal Primary and andidate keys (i) relation R may have more than one potential key, i.e. identifying, minimal attribute subset of R. (ii) potential key of R is called andidate key * of R. (iii) The Primary Key of R is an arbitrary candidate key RETE TLE Student( f VRHR (20), VRHR (30)NOT NULL, VRHR (40), matrno INTEGER PRIMRY KEY) ut matrno ++ is not a PK not minimal ut two or more attributes together may constitute a key: ++ f?? 04-DS-ER-RDM-7 RETE TLE ( f VRHR (20), VRHR (30)NOT NULL, birthdate DTE, Primary key with VRHR (40), more than one jobdesc VRHR(200) attribute as ONSTRINT region_pk separate, table PRIMRY KEY (,birthdate)) constraint. user defined constraint,.. why? * Schlüsselkandidat nie Kandidatenschlüssel 04-DS-ER-RDM-8 rtificial Keys Sometimes useful, to assign an artificial key to relation R RETE TLE ( p# INTEGER PRIMRY KEY, f VRHR (20), VRHR (30), RETE TLE LogRecords( seq# INTEGER PRIMRY KEY, logtype HR, logentry VRHR (300), time TIMESTMP) Surrogates: system internal row keys for special purposes Not an artificial key, exists in reality. rtificial, should be e.g.: 1,2... Postgres: SERIL Oracle:use sequence generator Operations on tables Why "Relational lgebra"? arla Operations on tables result in tables! e.g. select some rows: "s in IT-" project columns: "Names of all employees" "join" columns: " location of Müller" arla deptm Müller IT Katz Sales Maus IT deptm Müller IT Katz Sales Maus IT p# p# boss location Sales cc IT MUE Sales cc IT boss location MUE 04-DS-ER-RDM-9 04-DS-ER-RDM-10 RDM: Foreign Keys Foreign key RETE TLE ( p# INTEGER PRIMRY KEY, f VRHR (20), VRHR (30), deptm VRHR(20) FOREIGN KEY FK_Dep REFERENES ) RETE TLE ( VRHR (20) PRIMRY KEY, boss Integer, location VRHR (5) Foreign Key FK_oss REFERENES ) Implements 1:N relationship 1 has N 04-DS-ER-RDM-11 Def: foreign key is one or more attributes FK of a relation S, with the properties: (1) attributes of FK have the same domains as the attributes of key* p k of a relation R and (2) a value of FK in row of S either occurs as a value of the primary key for some row in R or is NULL. Def.: Referential integrity of a database is preserved, if all (explicit) foreign key constraint hold. * Usually the primary key, but not required! 04-DS-ER-RDM-12 2

3 What next: : From entities to tables Map E-R design to relational schema Define relational schema, table s, attributes and types, invariants Design steps: Translate entities into relations Translate relationships into relations Simplify (consolidate) the design Formal analysis of the schema (postponed) Define tables in SQL Define additional invariants 3.2 From onceptual to Logical schema Entity (types) with keys tables (schema relations) Key attributes in the onceptual model are primary keys in the RDM Weak entities: add primary key of superior entity to partial key of weak entity Example: country(c_id,, gnp,..) region(, population, area,..) partial key region (c_id, 04-DS-ER-RDM-13 never NULL, why? 04-DS-ER-RDM-14 Mapping Relationships Relationships in general: tables (schema relations) Relationships to tables 1:1-relationship hose as key one of the keys of the involved relations Dep ttributes: keys of the involved relations and attributes of the relationship Key of the "relationship" table: one or all keys of the related relations (1,1) has (0,*) Has d_ emp# Empl Each has unique emp# row in D_E identifies by emp# key is emp# ountry ountry(c_id, or (0,1) isapital (1,1) isapital (c_id,,r_id) isapital (c_id,,r_id) ity ity (, r_id, 04-DS-ER-RDM DS-ER-RDM-16 Relationships to tables 1:N relationship Dep(, boss, location) 1 N (1,1) (0,*) has has (p#, ) (p#, f,..) table R representing an 1:N E-R-relationship has as attributes the keys of both relations and relationship attribute of any as its key the key of the "N-side entity type" N:M relationship Userccount user(account,, (1,*) (0,*) MailMessage M N hasmail hasmail(account, msgid) MM(msgId Neither account nor msgid alone have key property separate table R representing an M:N E-R relationship has as attributes the keys of both relations and relationship attribute of any as key the keys of both entities N-ary relationship: all keys make up the new key 04-DS-ER-RDM DS-ER-RDM-18 3

Multi-valued attributes Multiple value attribute weak entity with a single attribute 3.2.3 onsolidation Def.

4 Multi-valued attributes Multiple value attribute weak entity with a single attribute onsolidation Def.: onsolidation (simplification) of a relational scheme is the process of merging those table (schemas) having the same key attributes into one table schema (recursively) ustomer : String f_: String c_#: Serial {phone: PhoneNo} streetno: String zip: Zipcode ity: String (1,1) (1,*) Phone pno: PhoneNo Relations: ustomer(, c_#,..) Phone(c_#, pno) R( k1,..,kn, a1, an), S( k1,,kn, b1, bm) RS( k1,,kn, a1, an,b1,,bm) Dep(, boss, location) has (p#, ) (p#, f,..)... or array-type / list type for attribute (Oracle, PostgresSQL and others). (p#, depname,, f,..) 04-DS-ER-RDM DS-ER-RDM-20 Example onsolidation: example 1 : 1 - relationship ountry (c_id,, isapital (c_id,, region) ountry(c_id,, capital, region, ) Foreign key red, path expression Region. not allowed RETE TLE ountry ( VRHR(32) NOT NULL, _ID VRHR(4) PRIMRY KEY, population INT, growth NUMERI(4,1), area INT, GNP INT, capital VRHR(25) NOT NULL, -- red region VRHR(4) NO NULL, type_of_gov VRHR(35), head_of_gov VRHR(70) ONSTRINT fk_capital FOREIGN KEY (capital, region) REFERENES ity) 04-DS-ER-RDM DS-ER-RDM-22 E-R R to RDM mapping: discussion Schema reengineering Transformation - unambiguous for relations representing 1:N relationship,... but consolidation optional. - 1:1 relationships: choice - merge with one of the entity- tables - M:N relationships: never merge Represented always by separate tables in the RDM Very simple process: Many D-Design tools model relationships directly by means of foreign keys! 04-DS-ER-RDM DS-ER-RDM-24 4

5 Discussion continued lways merge 1:N relationships? Example: Person(id,, phone#, Room (rno, building#, size, netsocket# Sits_in(id, rno,b#, since, gotkey, numberofkey, Merge would result in a relation with many NULL values Merging 1:N relationships makes sense in most cases If relationship has many attributes do not merge when many NULL values expected If attributes of relationship are used infrequently by applications, do not merge (*) Discussion(2) Never merge M:N relationships Person(id,, Hobby (hobby, kind, class_of_risk) has_h(id, hobby, casualty) Person(id,,..., hobby, casualty Key has been changed, redundancy introduced (*) efficiency argument: avoid unnecessary data transfers 04-DS-ER-RDM DS-ER-RDM E-R E R to RDM mapping: Generalization s: T1 x: T0 y: T1 t: T2 checking limit: num account.. saving interest: num Generalization: separate tables Second lternative: separate relations for, and make a one-to-one correspondence between every tuple from and the appropriate s..and the same for the s First alternative: One "big" -table with attributes from all specializations (x, y, s, t) NULLs, if subtypes are disjoint Empty, if subtypes are exhaustive i.e. each must belong to a subtype 04-DS-ER-RDM-27 (x, y) (x, s) (x, t) and are separate relations In this example: - disjoint specializations - not exhaustive Key of as foreign key and part of primary key in and (existence dependency) 04-DS-ER-RDM-28 E-R R to RDM mapping: Generalization Third alternative Extend by and, respectively (x,y,s) (x,y,t) Required: Subtypes must be exhaustive, i.e. complete specialization Think about the pros and cons of each solution! E-R R to RDM mapping Recursive relationships staff (0,*) boss (1,1) is_manager-of (eid,., managed_by_eid, ) Transformation step depending on cardinalities just like non-recursive relationships 04-DS-ER-RDM DS-ER-RDM-30 5

3. Schema Design: Logical Design using the Relational Data Model

3. Schema Design: Logical Design using the Relational Data Model 3.1 Logical Schema Design 3.1.1 The Relational Data Model in a nutshell 3.1.2 Keys, candidate keys and more 3.2 From Conceptual to Logical