Chuyển các mô hình lưu trữ dữ liệu bằng mô hình CSDL quan hệ (Relational Database)

sang mô hình CSDL hướng tài liệu (Document Database): bằng nhiều kiểu mô hình khác
nhau và nêu giả thiết để thấy được lý do tại sao thiết kế lưu trữ theo mô hình đó

Bài 1:

Mô hình 1 : Nhúng professions vào user

Users

_id: <Object> ,

first_name: "varchar",

surname: “varchar",

cell: ‘int’,

city: "varchar",

location_x: float ,

location_y: float ,

Professions
 {

_id: <Object>,

Profession: "banking"

Cars

_id:<Object>

model’:’varchar’

year:date

user_id:’Object’

Giải thích :

Chúng em sử dụng mô hình này khi mình thường xuyên truy vấn đến hai     collections
( User ,  Professions) , còn collection Cars thì không cần truy vấn đến nó nhiều cho nên
mình đề xuất mô hình này .

Mô hình 2 : Nhúng Cars vào User

Users

_id: <Object> ,

first_name: "varchar",

surname: “varchar",

cell: ‘int’,
 city: "varchar",

location_x: float ,

location_y: float ,

Cars

_id:<Object>

model’:’varchar’

year:date

Professions

_id: <Object>,

Profession: "banking"

user_id:<Object>

Mô hình 3:
Giải thích: Nhúng document car vào trong document user để tiện cho việc quản lý Cars.
Tách profession để truy vấn với tốc độ nhanh.
Mô hình 4:

Giải thích: Nhúng tất cả document vào trong 1 document user để tiện cho việc quản lý tất
cả các thông tin. Không bị trùng lặp dữ liệu quá nhiều, tiết kiệm bộ nhớ.

Bài 2:
 

Mô hình 1:  Nhúng Courses vào Students

Student {   

_id: <Object>,
Name:’String’

Courses {

_id:<Object>,

Name : ‘String’ 

 }

Dùng mô hình này vì : em nếu truy vấn 2 collections cùng 1 lúc (Students, Courses) 

Mô hình 2 :  không nhúng 

Students {   

_id: <Object>,

Name:’String’

Courses {

_id:<Object>,

Name : ‘String’

Em dùng mô hình này vì hệ thống thường xuyên truy vấn thông tin nhanh hơn vì nó
không có liên kết với collection khác  nên tốc độ truy vấn  dữ liệu sẽ nhanh hơn .

Bài 3:
Mô hình 1 :

Name: "Fido",

Food: "Dry",

Good Boy: "Y"

},

Name: "Rex",

Food: "Wet",

Good Boy: "N"

},

Name: "Bubbles",

Food: "Dry",

Good Boy: "Y"

},
{

Name: "Cujo",

Food: "Wet",

Good Boy: "N"

Tag#: 1573,

Height(in): 15,

Weight(lbs): 21

},

Tag#: 2684,

Height(in): 9,

Weight(lbs): 7

},

Tag#: 3795,

Height(in): 27,

Weight(lbs): 130

},

Tag#: 4806,

Height(in): 6,
 Weight(lbs): 5

Tag#: 1573,

Name: "Fido",

Breed: "Beagle",

Color: ["Brown", "While"],

Age: 1.5

},

Tag#: 2684,

Name: "Rex",

Breed: "Pekingese",

Color: "While",

Age: 9

},

Tag#: 3795,

Name: "Bubbles",

Breed: "Rottwller",

Color: "Black",

Age: 5

},
{

Tag#: 4806,

Name: "Cujo",

Breed: "Chihuahua",

Color: "Gold",

Age: 4

Ưu điểm: dễ thực hiện các lệnh truy vấn, các câu truy vấn có tốc độ thực hiện nhanh
chóng.

Nhược điểm: mô hình quá ròm rà, dài, dữ liệu bị trùng lắp quá nhiều

Tag#: 1573,

Name: "Fido",

Breed: "Beagle",

Color: ["Brown", "White"],

Age: 1.5

Food: "Dry",

Good Boy: "Y",

Height(in): 15,

Weight(lbs): 21

},

{
 Tag#: 2684,

Name: "Rex",

Breed: "Pekingese",

Color: "White",

Age: 9

Food: "Wet",

Good Boy: "N",

Height(in): 9,

Weight(lbs): 7

},

Tag#: 3795,

Name: "Bubbles",

Breed: "Rottweiler",

Color: "Black",

Age: 5

Food: "Dry",

Good Boy: "Y",

Height(in): 27,

Weight(lbs): 130

},

Tag#: 4806,

Name: "Cujo",
 Breed: "Chihuahua",

Color: "Gold",

Age: 4

Food: "Wet",

Good Boy: "N",

Height(in): 6,

Weight(lbs): 5

Ưu điểm: dữ liệu không bị trùng lắp,

Bài 4:

MÔ HÌNH 1 : Nhúng BASE , TYPE vào TRUCK

TRUCK

{ 
TNUM: <Object>,

BASENUM:INT,

TYPENUM:{    

TYPEDESC: { Array}

TMILES:float,

TBOUGHT:date,

TSERIAL:string

BASE{

BASENUM:<Object>,

BASECITY: ‘’String’’,

BASESTATE:”String”,

BASEPHON:String,

BASEMGR:String

Em dùng mô hình này là vì : khi cần truy vấn thông tin dữ liệu cùng 1 lúc thì ta sẽ đơn
giản hóa tra cứu dữ liệu, tiết kiệm thời gian.

MÔ HÌNH 2 : Nhúng BASE vào TRUCK

TRUCK[{

         TNUM:<Object>
                BASE{

BASENUM:<Object>,

BASECITY: ‘’String’’,

BASESTATE:”String”,

BASEPHON:String,

BASEMGR:String

TMILES:float,

TBOUGHT:date,

TSERIAL:string

        

TYPE{

         TYPENUM:<Object>

         TYPEDESC:STRING

         TNUM:<Object>

Giải thích:

 Chúng em sử dụng mô hình này khi mình thường xuyên truy vấn đến hai      collections (
Truck , Base ) , còn collection Type thì không cần  truy vấn đến nó nhiều cho nên mình
đề xuất mô hình này 

 
 

Bài 5:

MÔ HÌNH I : Nhúng  WORK_POSITIONS

USER{

         _ID : ‘OBJECT’

         NAME :’VARCHAR’

         AGE: ’INT’

         ADDRESS:’VARCHAR’

WORK_POSITIONS  : ARRAY

         _ID:’OBJECT’

         POSITIONS:’VARCHAR’

         SALARY:’FLOAT’

        }

UNIVERSITY

         _ID:’OBJECT’

         NAME:’VARCHAR’

         INDEX:’INT’

USER_ID:’OBJECT’

 Giải thích :

 Chúng em sử dụng mô hình này khi mình thường xuyên truy vấn đến hai     collections
( User , Work_Position ) , còn collection UNIVERSITY thì không cần truy vấn đến nó
nhiều cho nên mình đề xuất mô hình này 

MÔ HÌNH 2 : Nhúng Univercity

USER{
         _ID : ‘OBJECT’

         NAME :’VARCHAR’

         AGE: ’INT’

         ADDRESS:’VARCHAR’

UNIVERSITY : ARRAY

         _ID:’OBJECT’

         NAME:’VARCHAR’

         INDEX:’INT’

        }

WORK_POSITIONS  

         _ID:’OBJECT’

         POSITIONS:’VARCHAR

SALARY:’FLOAT’

USER_ID:’OBJECT’

 Giải thích :
 Chúng em sử dụng mô hình này khi mình thường xuyên truy vấn đến hai     collections
( User , Univercity) , còn collection Work_position thì không cần truy vấn đến nó nhiều
cho nên mình đề xuất mô hình này