Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 The Relational Model & Relational Mapping.

Similar presentations


Presentation on theme: "1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 The Relational Model & Relational Mapping."— Presentation transcript:

1 1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 The Relational Model & Relational Mapping These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see http://www.openlineconsult.com/db

2 2 © Ellis Cohen 2001-2008 Overview of Lecture Representing Relationships as Bridge Tables Relational Models & Referential Integrity Foreign Keys Relational Mapping of 1:M Relationships Relational Mapping Exercises Mapping Reflexive Relationships Conceptual & Relational Models Defining and Changing Attributes Assigning Sequential & Unique Values to Attributes Metadata & System Data

3 3 © Ellis Cohen 2001-2008 Representing Relationships as Bridge Tables

4 4 © Ellis Cohen 2001-2008 Implementing Conceptual Models A conceptual model abstractly describes the information we want to persistently store in a database. But, how do we actually represent the model using the tables provided by a relational database?

5 5 © Ellis Cohen 2001-2008 Entity Classes  Tables Make each entity class a table Each attribute of the entity class becomes an attribute (i.e. a column) of the table Define a primary key for the entity class if necessary The primary key of the entity class becomes the primary key of the table Emps 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr 7499ALLEN10 Lehigh Way, … 7654MARTIN22 Gleason St, … 7844TURNER… 7212LAVICH… 7698BLAKE… 7986STERN…

6 6 © Ellis Cohen 2001-2008 Linking Instances 7698BLAKE12 Rara Road 7499ALLEN15 Pogo Lane 7654MARTIN… 7986STERN… 7844TURNER… 30SALES 10ACCOUNTING 7212LAVICH… Dept works for Employee deptno empno Child Entity ClassParent Entity Class Relational databases don't actually have "relationships". How do we implement them?

7 7 © Ellis Cohen 2001-2008 Represent Links by a Bridge Table Emps 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr empno deptno WorksFor 749930 765430 784430 769810 798610 7499ALLEN… 7654MARTIN… 7844TURNER… 7212LAVICH… 7698BLAKE… 7986STERN… Dept works for Employee deptno empno Child Entity ClassParent Entity Class Suppose an employee does not have a department? Suppose an a department does not have any employees? What's the primary key of WorksFor?

8 8 © Ellis Cohen 2001-2008 Table-Based Mapping 1.Make each entity class a table 2.Make each relationship a table 3.Combine tables with the same primary keys to make queries of the related tables more efficient (usually)

9 9 © Ellis Cohen 2001-2008 Combine WorksFor with Emps 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH… 7698BLAKE…10 7986STERN…10 Emps 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr empno deptno WorksFor 749930 765430 784430 769810 798610 7499ALLEN… 7654MARTIN… 7844TURNER… 7212LAVICH… 7698BLAKE… 7986STERN… Suppose an employee does not have a department?

10 10 © Ellis Cohen 2001-2008 Reference Columns Help Match Information for Querying 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH… 7698BLAKE…10 7986STERN…10 Emps Suppose we want to find out the name of the Department that BLAKE works in A query can 1.Determine BLAKE's department #  10 2.Determine the name of department #10 We find the tuple in Depts where Depts.deptno matches Emps.deptno We will see shortly how SQL Joins can obtain this information in a single query!

11 11 © Ellis Cohen 2001-2008 Relational Models & Referential Integrity

12 12 © Ellis Cohen 2001-2008 Associated Columns empno ename addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH… 7698BLAKE…10 7986STERN…10 Emps Every employee has a single empno, ename, addr, and a single deptno (which may be NULL if the employee is unassigned) The value of the deptno column identifies another tuple – the tuple which represents the employee's department

13 13 © Ellis Cohen 2001-2008 Referential Integrity 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH… 7698BLAKE…10 7986STERN…10 Emps In fact, we want to check that every value of deptno in Emps identifies a legal department – that is, it must match a deptno value in Depts. This is called "referential integrity"

14 14 © Ellis Cohen 2001-2008 SQL Representation CREATE TABLE Depts( deptno number(3) primary key, dname varchar(20) ) CREATE TABLE Emps( empno number(4) primary key, ename varchar(30), addr varchar(80), deptno number(3) references Depts(deptno) ) referential integrity constraint

15 15 © Ellis Cohen 2001-2008 Referential Integrity Example Emps( empno, ename, addr, deptno ) deptno references Depts( deptno ) Every value in Emps.deptno is in Depts.deptno  NULLs in Emps.deptno are OK  Not every value in Depts.deptno needs to be in Emps.deptno (e.g. 50 isn't) 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH… 7698BLAKE…10 7986STERN…10 Emps

16 16 © Ellis Cohen 2001-2008 Referential Integrity Violation Emps( empno, ename, addr, deptno ) deptno references Depts( deptno ) is violated, since Emps.deptno contains a value (70), which is not in Depts.deptno The database will NOT allow this! 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH…70 7698BLAKE…10 7986STERN…10 Emps

17 17 © Ellis Cohen 2001-2008 Relational Models A Relational Model describes –The characteristics of each relation (i.e. table) –Including any referential integrity constraints SQL is a textual description of a relational model Relational Schema Diagrams are a visual description of a relational model

18 18 © Ellis Cohen 2001-2008 Relational Schema Diagrams Depts( deptno, dname ) Emps( empno, ename, addr, deptno ) deptno references Depts( deptno ) VISUAL Relational Model (Relational Schema) BRIEF TEXTUAL Relational Model (TRex) Emps empno ename addr deptno Depts deptno dname referential integrity constraint

19 19 © Ellis Cohen 2001-2008 Relational Schemas as 1:M Relationships Emps empno ename addr deptno Depts deptno dname 1 2 3 1. The primary key of Emps is empno  The values of empno are all unique and non-null  Every employee has a single empno, a single ename, and a single addr, but moreover … 2. Every employee has a single deptno However, multiple employees could have the same deptno  There's a 1:M relationship between employees and whatever deptno represents 3. deptno represents a department (but multiple empno's could have the same value for deptno), so there's 1:M relationship between employees and department * EmployeeDept works for

20 20 © Ellis Cohen 2001-2008 What's Wrong? Emps empno ename addr Depts deptno dname empno X What's wrong with this representation? WRONG! Don't do this!

21 21 © Ellis Cohen 2001-2008 Only One Employee per Dept! Emps empno ename addr Depts deptno dname empno X This relation has one tuple per department So, each department has a single empno value associated with it! That means that a department can have at most a single employee!

22 22 © Ellis Cohen 2001-2008 Foreign Keys

23 23 © Ellis Cohen 2001-2008 Possible Referential Integrity Emps empno ename addr hiredate Projs pno pname budget startdate What might this mean, based on referential integrity? Is it legal? ?

24 24 © Ellis Cohen 2001-2008 empno ename address hiredate pno pname budget startdate Illegal Referential Integrity X What might this mean? If a value for a hiredate is in Emps, then the same value for startdate MUST be in Projs: Employees could only be hired on the day some project started! Is it legal? No. We only allow foreign key constraints, where the attributes referenced (e.g. startdate) MUST BE unique (preferably a primary key). Projs.startdate is almost certainly not unique. Why only foreign key constraints? Commercial databases only support foreign key constraints; some only allow references to primary keys EmpsProjs

25 25 © Ellis Cohen 2001-2008 Foreign Key Constraint A foreign key constraint is a referential integrity constraint, where the referenced column (s) must have unique values. The standard relational model only uses foreign key constraints referenced column has UNIQUE values Foreign Key Constraint Foreign Key The database continually checks that a foreign key value matches a value of the referenced attribute –on insert/update of the foreign key, or –on update/delete of the referenced attribute(s) Changes that violate the constraint are disallowed (there are other ways of handling this as well …) Emps( empno, ename, addr, deptno ) deptno references Depts( deptno )

26 26 © Ellis Cohen 2001-2008 Foreign Primary Key Constraint A foreign primary key constraint is a foreign key constraint, where the referenced column (s) is a primary key. Emps( empno, ename, addr, deptno ) deptno references Depts Foreign Primary Key Constraint Foreign Key The referenced column does not need to be explicitly listed because it is the primary key of Depts

27 27 © Ellis Cohen 2001-2008 SQL Representation CREATE TABLE Depts( deptno number(3) primary key, dname varchar(20) ) CREATE TABLE Emps( empno number(4) primary key, ename varchar(30), addr varchar(80), deptno number(3) references Depts)

28 28 © Ellis Cohen 2001-2008 Relational Mapping of 1:M Relationships

29 29 © Ellis Cohen 2001-2008 Conceptual & Relational Models A conceptual model Abstractly represents the database design Based on entity classes & relationships A relational model Concretely represents the details of the database design using relations (tables) Relationships are not built-in to the relational model. They are implemented referential integrity constraints. A relation is the mathematical term for a table. So the relational model is about how the tables are modeled in the actual database. The relational model is NOT about relationships

30 30 © Ellis Cohen 2001-2008 Database Design Process Requirements Physical Model using DDL & DCL Relational Model Conceptual Model Conceptual Design & Conceptual Normalization Relational Mapping & Relational Normalization Physical Mapping

31 31 © Ellis Cohen 2001-2008 Linking Instances 7698BLAKE12 Rara Road 7499ALLEN15 Pogo Lane 7654MARTIN… 7986STERN… 7844TURNER… 30SALES 10ACCOUNTING 7212LAVICH… Dept works for Employee deptno empno Child Entity ClassParent Entity Class Map to a relational model to implement the links between instances

32 32 © Ellis Cohen 2001-2008 Table-Based Mapping 1.Make each entity class a table 2.Make each relationship a table (with foreign keys) 3.Combine tables with the same primary keys to make queries of the related tables more efficient (usually)

33 33 © Ellis Cohen 2001-2008 Column Based Mapping 1.Make each entity class a table 2.Represent a 1:M relationship by adding a foreign key (no need to consider bridge tables)

34 34 © Ellis Cohen 2001-2008 Representing Links by Foreign Keys 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr deptno 7499ALLEN...30 7654MARTIN…30 7844TURNER…30 7212LAVICH… 7698BLAKE…10 7986STERN…10 Emps An explicit reference to a tuple in the table for the Parent Entity Class Dept works for Employee Child Entity ClassParent Entity Class deptno empno At most a single dept is associated with an employee. Identify that department

35 35 © Ellis Cohen 2001-2008 Crow Magnum & Relational Schemas DeptEmployee works for deptno dname empno ename addr Emps empno ename addr deptno Depts deptno dname foreign key constraint Visual CONCEPTUAL Model (Crow Magnum) Visual RELATIONAL Model (Relational Schema) Does NOT include deptno deptno * Child Entity ClassParent Entity Class

36 36 © Ellis Cohen 2001-2008 Chen & Relational Schemas Emps empno ename addr deptno Depts deptno dname Visual CONCEPTUAL Model (Chen) Visual RELATIONAL Model (Relational Schema) Chen Employee Dept works for Note the arrows point in the same direction!

37 37 © Ellis Cohen 2001-2008 The Relational Schema Arrow Hint DeptEmployee works for deptno dname empno ename addr Emps empno ename addr deptno Depts deptno dname Child Entity ClassParent Entity Class In a 1:M relationship, the Crow's Foot symbol points to the parent entity class The reference arrow points in the same direction

38 38 © Ellis Cohen 2001-2008 Relational Mapping Exercises

39 39 © Ellis Cohen 2001-2008 Reverse Engineering Exercise Design Corresponding ER Models for each of these HealthPlans Players planid plannam plantyp playid pnam teamid planid Teams teamid tnam Emps Depts empno ename sal deptno hirediv deptno dname divid Divs divid divnam

40 40 © Ellis Cohen 2001-2008 Interpreting Exercise 1 HealthPlans Players planid plannam plantyp playid pnam teamid planid Teams teamid tnam Each player (identified by playid) has a single pnam a single teamid (but many players could reference the same team) a single planid (but many players could reference the same plan)

41 41 © Ellis Cohen 2001-2008 Answer to Exercise 1 Visual CONCEPTUAL Model (Easy Crow Magnum) TeamPlayerHealth Plan has enrolled in teamid tnam playid pnam planid plannam plantyp Visual RELATIONAL Model: Relational Schema HealthPlans Players planid plannam plantyp playid pnam teamid planid Teams teamid tnam Note direction of Crow Magnum indicators & reference arrows I use singular for entity class names, plural for table names

42 42 © Ellis Cohen 2001-2008 Answer to Exercise 2 Visual CONCEPTUAL Model (Easy Crow Magnum) DivisionDeptEmployee part of works for initially hired divid divnam deptno dname empno ename sal Visual RELATIONAL Model (Relational Schema) Note direction of Crow Magnum indicators & reference arrows Emps Depts empno ename sal deptno hirediv deptno dname divid Divs divid divnam I use singular for entity class names, plural for table names

43 43 © Ellis Cohen 2001-2008 Merging Foreign Key Lines Emps Depts empno ename sal deptno hirediv deptno dname divid Divs divid divnam Emps Depts empno ename sal deptno hirediv deptno dname divid Divs divid divnam When two foreign keys reference the same attribute, you can merge the lines (Don't do this in ER diagrams though!) Could two different Emps attributes both reference divid?

44 44 © Ellis Cohen 2001-2008 Mapping Exercise Design Corresponding Relational Schemas for each of these StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam PlayerChild has childid cname playid pnam Team has teamid tnam gives scholarship to

45 45 © Ellis Cohen 2001-2008 Interpreting Mapping Exercise 1 StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam Items Styles itemsku size color stylecode stylenam styledate catid Each style is associated with a single category Each item is associated with a single style

46 46 © Ellis Cohen 2001-2008 Answer to Mapping Exercise 1 StyleItem has itemsku size color stylecode stylenam styledate Category has catid catnam Visual CONCEPTUAL Model (Easy Crow Magnum) Visual RELATIONAL Model (Relational Schema) Items Styles itemsku size color stylecode stylenam styledate catid Categories catid catnam Arrowheads are REQUIRED! Note direction of Crow Magnum indicators & reference arrows

47 47 © Ellis Cohen 2001-2008 Answer to Mapping Exercise 2 Visual CONCEPTUAL Model: Easy Crow Magnum ER Diagram Visual RELATIONAL Model: Relational Schema Children Players childid cname playid schteamid playid pnam teamid Teams teamid tnam PlayerChild has childid cname playid pnam Team has teamid tnam gives scholarship to

48 48 © Ellis Cohen 2001-2008 Keeping the Bridge Table Emps 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr empno deptno WorksFor 749930 765430 784430 769810 798610 7499ALLEN… 7654MARTIN… 7844TURNER… 7212LAVICH… 7698BLAKE… 7986STERN… Dept works for Employee deptno empno Child Entity ClassParent Entity Class Occasionally, relational designs keep bridge tables for 1:M relationships. If so, what would be the corresponding relational schema?

49 49 © Ellis Cohen 2001-2008 Relational Schema with Bridge Table Emps 30SALES 10ACCOUNTING 50SUPPORT deptno dname Depts empno ename addr empno deptno WorksFor 749930 765430 784430 769810 798610 7499ALLEN… 7654MARTIN… 7844TURNER… 7212LAVICH… 7698BLAKE… 7986STERN… Depts WorksFor deptno dname empno deptno Emps empno ename addr

50 50 © Ellis Cohen 2001-2008 Mapping Reflexive Relationships

51 51 © Ellis Cohen 2001-2008 Mapping Reflexive 1:M Relationships Emps empno ename mgr 7499ALLEN…7698 7654MARTIN7698 BLAKE7839 KING 7844TURNER7698 7986STERN7839 Add mgr to Emps, referencing empno Employee manages

52 52 © Ellis Cohen 2001-2008 Schema for Reflexive Relationships Dept works for deptno dname empno ename addr Emps empno ename addr deptno mgr Depts deptno dname Visual CONCEPTUAL Model (Crow Magnum ER Diagram) Visual RELATIONAL Model (Relational Schema) Does NOT include deptno or mgr Employee manages *

53 53 © Ellis Cohen 2001-2008 Visual & Brief Textual Relational Models Depts( deptno, dname ) Emps( empno, ename, addr, deptno, mgr ) deptno references Depts mgr references Emps VISUAL Relational Model (Relational Schema) BRIEF TEXTUAL Relational Model (TRex) Emps empno ename addr deptno mgr Depts deptno dname

54 54 © Ellis Cohen 2001-2008 SQL Representation CREATE TABLE Depts( deptno number(3) primary key, dname varchar(20) ) CREATE TABLE Emps( empno number(4) primary key, ename varchar(30), addr varchar(80), deptno number(3) references Depts, mgr number(4) references Emps )

55 55 © Ellis Cohen 2001-2008 Conceptual and Relational Models

56 56 © Ellis Cohen 2001-2008 Database Design Process Requirements Physical Model using DDL & DCL Relational Model Conceptual Model Conceptual Design & Conceptual Normalization Relational Mapping & Relational Normalization Physical Mapping Why not just design the relational model directly from the requirements? Why design an intermediate conceptual model?

57 57 © Ellis Cohen 2001-2008 Why Do Conceptual Design? Faster to create & draw a conceptual model Clearer semantic intent Easier to understand and reason about Many ways to design a relational model for a given conceptual model Focus on essential design decisions Allows secondary design decisions to be deferred

58 58 © Ellis Cohen 2001-2008 Combining the Conceptual & Relational Models Emps empno ename addr deptno mgr Depts deptno dname works for manages Some modeling tools and technologies combine the conceptual and the relational model. We think it is better to keep the two distinct

59 59 © Ellis Cohen 2001-2008 UML Combination of Conceptual & Relational Models Using UML to combine the conceptual and the relational model. We've placed the association link adjacent to the foreign key (FK) which implements it. However, this is actually rarely done when FK's are shown in UML, which can make it hard to tell which FK represents which relationship EmployeesDepts works for * 0..1 PK empno ename addr FK deptno FK mgr PK deptno dname manages * 0..1

60 60 © Ellis Cohen 2001-2008 Why Different Models? Dept works for Emps empno ename addr deptno mgr Depts deptno dname Visual CONCEPTUAL Model (Crow Magnum ER Diagram) Visual RELATIONAL Model (Relational Schema) Employee manages Used for communication among system & UI architects and users, interested more in functionality than implementation Used for communication among database designers and administrators, focused on implementation

61 61 © Ellis Cohen 2001-2008 Defining and Changing Attributes

62 62 © Ellis Cohen 2001-2008 Identifying Rows in Tables Numeric Id Uniquely identifies row without providing information about row's real identity or contents - e.g. 304792 Structured Id (e.g. SKU) Often structured to reflect structure or practice of organization - e.g. XM-304-T Can causes problems if structure or practice of organization changes Short Name Name that uniquely identifies row to DBA - e.g. ACCT Long Name / Title Name that clearly and uniquely identifies row to user - e.g. ACCOUNTING

63 63 © Ellis Cohen 2001-2008 Naming Columns Use a consistent naming approach Column name includes (whole or partial) name of table [in Emps] empno and [in Depts] deptno (or) [in Emps] empid and [in Depts] deptid [in Emps] ename and [in Depts] dname Column name is independent of table name [in Emps] id and [in Depts] id to identify the primary key [in Emps] name and [in Depts] name to identify the employee & department name –Simplest naming model –Tends to require relative names [Emps.id] with queries joining multiple tables –Possibility of spurious join columns when using natural joins

64 64 © Ellis Cohen 2001-2008 Naming Foreign Keys Use name of foreign key, with table name included, if necessary: e.g. [in Emps] deptno (or deptid) Where that name is ambiguous, replace or combine with a name that reflects the role in the local table e.g. [in Emps] use mgr or (better) mgrno to refer to the empno of the employee's manager

65 65 © Ellis Cohen 2001-2008 Altering Column & Tables ALTER TABLE Emps ADD ( numkids int not null default 0 ) –Adds column ALTER TABLE Emps MODIFY ( sal NUMBER(13,2) DEFAULT 250 ) –Modifies column datatype and/or default ALTER TABLE Emps DROP (numkids, sal) –Drops columns ALTER TABLE Emps RENAME TO Employees –Renames entire table (can't rename columns)

66 66 © Ellis Cohen 2001-2008 Assigning Sequential & Unique Values to Attributes

67 67 © Ellis Cohen 2001-2008 Choosing a Primary Key User-provided Id or Name Provided by user when tuple in created System-provided Id Provided by an id generator defined in the database system. Useful as a surrogate key even if a name or a user-provided key is available.

68 68 © Ellis Cohen 2001-2008 System-Provided Id Generator Id Values –Sequential (1,2,3,…) –Globally unique id (GUID) Every id generated is globally unique Useful if merging separate databases Id Generation –Explicit (used by Oracle) Handled through a named database object, which is explicitly incremented, gotten and stored in some column of a new row Via PL/SQL, can be made to look automatic –Automatic (used by SQL Server) Associated with a table column (A specified column in each newly created row gets a new id, sort of like Oracle ROWIDs)

69 69 © Ellis Cohen 2001-2008 Sequences in Oracle Defining and using sequences CREATE SEQUENCE empseq START WITH 8000 INCREMENT BY 10 SELECT empseq.nextval FROM dual Imagine a single operation NewEmp( ename, deptno, job, sal, comm ) Inserts a tuple into emp with empseq.nextval  empno filled in from empseq.nextval  hiredate filled in with today's date  ename, deptno, job, sal, comm filled in from the given values An operation like this can be defined as a stored PL/SQL procedure UGLY This is UGLY! You'd really like to hide it

70 70 © Ellis Cohen 2001-2008 Generating Globally Unique Ids If you are not using a system that can provide GUID's, you can make one by concatenating together –Unique mac or ip address or name of machine –Name of database –Name of schema (i.e. user) –System-provided per-schema id (e.g. from an Oracle sequence) or timestamp For example cs.bu.edu-testdb-scott-80420 In Oracle, the function SYS_GUID() will return a globally unique id as a 16 byte RAW value

71 71 © Ellis Cohen 2001-2008 Metadata and System Data

72 72 © Ellis Cohen 2001-2008 Metadata & System Data Metadata is information about the data that users store in the database. For example, –the names of a user's tables –the names and types of table columns. More generally, system data, is data stored by the database to support its proper functioning. Databases generally store metadata and other system data in the database itself. –In relational databases, this information is stored in tables.

73 73 © Ellis Cohen 2001-2008 Basic Column Metadata Note that the column metadata for the Emps table can itself be represented as a table

74 74 © Ellis Cohen 2001-2008 Oracle Examples SELECT * FROM Dictionary where table_name like 'USER_TAB%' order by table_name; – Dictionary holds info about all tables in the DB – this selects info about user table metadata SELECT table_name FROM User_Tables; – this lists the names of the user's tables SELECT table_name, column_name FROM User_Tab_Columns ORDER BY table_name, column_name; – this lists the names of the columns of each of the user's tables


Download ppt "1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 The Relational Model & Relational Mapping."

Similar presentations


Ads by Google