CHƯƠNG CHƯƠNG 1212::
MôMô hìhìnhnh ddưữ ̃ liliệệuu
1

NNôộ̣ii dung dung
2
 So sánh mô hình dữ liệu và mô hình đối
tượng
 Quy tắc nghiệp vụ và tính logic trong mô
hình dữ liệu
 Trình tự tạo mô hình dữ liệu
◦ Từ việc thiết kế bảng
◦ Từ mô hình đối tượng
 Phát CSDL hay file DDL

Object Model và Data ModelObject Model và Data Model
 Mô hình Object được dùng cho hầu hết các
thành phần của ứng dụng như class, attributes,
operations, relationships, components, và các
cấu trúc khác (ngoại trừ dữ liệu) liên quan đến
tính hiệu quả của bộ nhớ
◦ Đối tượng gì được tạo trong bộ nhớ, chúng giao tiếp
nhau như thế nào, mỗi đối tượng có nhiệm vụ gì?
 Data model liên quan nhiều đến tính hiệu quả
của database.
3

So sánh 2 mô hìnhSo sánh 2 mô hình
4
So sánh So sánh 2 2 mô hìnhmô hình

Mô hình object Mô hình data
Tập trung vào
behavior và data
Chỉ tập trung vào
data
Hỗ trợ tính kế thừa
(inheritance)
Không hỗ trợ tính kế
thừa
Hai entity classes có
thể quan hệ với nhau.
Các bảng của entity
class có thể không
cần quan hệ với nhau
5

So sánh So sánh 2 2 mô hìnhmô hình
 Mô hình object hay data được phát triển
trước??
◦ Thường được phát triển đồng thời.
 Một entity class từ lược đồ class sẽ trở
thành các bảng của database CSDL.
Ngược lại, một bảng trong database có
thể được hỗ trợ bởi hai hay nhiều class
trong ứng dụng.
6

MMốối quan hi quan hệệ gigiữữa a 2 2 mô hìnhmô hình
 Nhiều project, chủ yếu là các project cần
nâng cấp, bắt đầu với một mô hình data

có sẵn, có thể reverse engineer mô hình
này để phát ra một mô hình object.
 Nếu có mô hình object nhưng không có
mô hình data, có thể phát tự động mô
hình data từ mô hình này.
7

Quy tQuy tắắc nghic nghiệệp vp vụụ Business rulesBusiness rules
 Nếu muốn thực thi mô hình data, cần phải áp
dụng các quy tắc nghiệp vụ (business rules) vào
mô hình.
 Các quy tắc nghiệp vụ bao gồm: yêu cầu, chính
sách, hướng dẫn cần thiết để hoàn tất giao dịch
trong thực tế.
 Khi áp dụng các quy tắc nghiệp vụ, phải chỉ ra
được:
◦ các giá trị có thể chấp nhận trong các cột (not null,
unique, default )
◦ Các biểu thức điều kiện (check constraint)
◦ Các hành động cần làm khi cập nhật database (trigger
bảo toàn tham chiếu)
8

Tính logic trong mô hình dTính logic trong mô hình dữữ liliệệu u
 Thực tế của hướng đối tượng chỉ ra rằng
nên giữ các business logic trong ứng dụng
hơn là trong database
 Chỉ có logic nào liên quan đến chính dữ
liệu mới nên đưa vào database như: các
field, giá trị hợp lệ trong các field, chiều dài

field…
9

Tính logic trong mô hình dTính logic trong mô hình dữữ liliệệu u
 Nhiều quy tắc nghiệp vụ (business rules) có thể
đựơc đưa trực tiếp vào database thông qua
constraint. Tuy database là nơi thích hợp cho loại
logic này, ứng dụng buộc phải thu thập thông tin
từ end user, truyền nó qua lớp business, qua kết
nối mạng trước khi dữ liệu được đánh giá. Nếu
để logic này ngay tại lớp business thì đôi khi giảm
được nghẽn mạng.
 Tuy nhiên 1 số phần trong ứng dụng hay các ứng
dụng khác, cần dùng cùng 1 constraint thì nên đặt
nó trong database để bảo đảm quy tắc này được
áp dụng 1 cách thống nhất.
10

Tính logic trong mô hình dTính logic trong mô hình dữữ liliệệu u
 Một số logic hệ thống có thể đặt ngoài
database trong các stored procedures.
Nếu chức năng liên quan đến việc tạo dữ
liệu thì nên lập trình nó trong stored
procedure có thể nhanh hơn là phải nạp
toàn bộ bản ghi vào bộ nhớ rồi để ứng
dụng xử lý, và lưu trữ kết quà ngược về
lại database.
11

Tính logic trong mô hình dTính logic trong mô hình dữữ liliệệu u

 Tuy nhiên cũng có những bất lợi khi dùng
stored procedure để thực thi business
logic:
◦ Chia business logic ngang qua ít nhất là 2
layer (business logic layer và the database
layer). Khi business logic thay đổi, có thể
cần cập nhật cả 2 layer
◦ Nếu dùng quá nhiều stored procedures
có thể khó di chuyển chúng từ DBMS
này sang DBMS khác do cú pháp có thể
khác nhau.
12

Tính logic trong mô hình dTính logic trong mô hình dữữ liliệệuu
 Không dễ quyết định logic nên đặt trong
database hay trong ứng dụng.
 Ngay khi quyết định đặt logic trong
database, có thể mô hình logic này bằng
cách mô hình hoá stored procedures,
constraints, và triggers.
13

TTạạo mô hình do mô hình dữữ liliệệuu
 Mô hình Data được xây dựng cả trong
logical view và Component view.
 Trong logical view, có thể tạo schema,
table, domain và các domain packages.
 Trong Component view, mỗi database
được mô hình như 1 component với
stereotype là <<database>>

14

Trình tTrình tựự ttạạo mô hình datao mô hình data
1. Tạo database
2. Tạo schema
◦ Logical view\Data Modeler\New\Schema
◦ Gán database cho schema
3. Tạo domain package
 Logical view\Data Modeler\New\ Domain
Package
 Gán hệ DBMS cho domain package
15

Trình tTrình tựự ttạạo mô hình datao mô hình data
4. Tạo các domain trong domain package
 Domain package\Data Modeler\New\Domain
5. Tạo lược đồ mô hình data
 Schema\Data Modeler\New\Data Model Diagram
6. Tạo hay thêm bảng vào lược đồ
 Tools\Create\Table, nhấp vào cửa sổ lược đồ
7. Tạo mối quan hệ giữa các bảng
8. Tạo view
9. Tạo mô hình object từ mô hình data
10. Phát ra database
11. Giữ database đồng bộ với mô hình data thông
qua tính chất Update
16

BBướướcc 11: : TaTạ̣oo DatabaseDatabase
 Rose hỗ trợ 1 số DBMS như sau:

◦ MS SQL server
◦ IBM DB2
◦ Oracle
17

BBướướcc 11: : TaTạ̣oo DatabaseDatabase
 Database được mô hình hoá như 1
component. Nó cần có tên riêng biệt và
phải được gán vào 1 DBMS xác định.
 Để tạo database:
◦ Tại Component view, nhấp phải và chọn lệnh
Data Modeler\ New\ Database
◦ Sau khi tạo DB, mở open specification và
chọn DBMS thích hợp.
18

TablespaceTablespace ((filegroupfilegroup))
 Khi sử dụng DB2, Oracle hay SQL server,
có thể thêm tablespace vào DB
 Tablespace là 1 đơn vị lưu trữ logical cho
các bảng.
◦ Mỗi tablespace chứa 1 hay nhiều container.
◦ Mỗi container là 1 thiết bị lưu trữ vật lý chẳng
hạn như đĩa cứng. Một container được chia
thành nhiều đơn vị nhỏ hơn gọi là extent.
◦ Các bảng được phân bổ ngang qua các
container trong cùng 1 tablespace
19

TablespaceTablespace

 Để tạo tablespace cho database:
Data Modeler\ New \ Tablespace
 Với SQL server, thì tablespace còn được
gọi là filegroup, container còn được gọi là
file.
 Mỗi tablespace đều có 1 kích cỡ ban đầu.
Ngay khi không gian này được dùng hết,
DBMS có thể tự động tăng thêm kích cỡ
với độ lớn được đặt sẵn nhưng không
thể vượt quá kích cỡ cực đại.
20

TablespaceTablespace
 Ngay khi các tablespace được xây dựng,
ta có thể gán các bảng vào chúng.
 Bất kỳ bảng nào nếu không được gán vào
một tablespace nào thi sẽ được gán vào
tablespace mặc định.
21

ContainerContainer
 Ngay sau khi đã xây dựng tablespace, nên
tạo các container
 Nên xác định filename, kích cỡ ban đầu
(initial size), kích cỡ cực đại(maximum
size) và mức độ tăng (file growth) cho
mỗi container.
22
SchemaSchema
 Schema là 1 container cho mô hình data , là nơi mà

dựa vào đó Data Modeler sẽ chuyển đổi mô hình
data thành mô hình object.
 Schema sẽ được ánh xạ thành 1 package của mô
hình object dù cho schema có nhiều chức năng
hơn là 1 component thông thừong của UML
 Tất cả tables, fields, triggers, constraints, và các
phần tử mô hình hóa dữ liệu khác đều được chứa
trong 1 schema ngoại trừ domain (đuợc lưu trong
domain packages) và database (được lưu trong
Component view).
23
SchemaSchema
 Tất cả các schema đều được lưu trong package
tên Schema nằm trong Logical.
 Mỗi schema phải được ánh xạ vào 1 database
trong mô hình. Mỗi database có thể chứa trong
một hay nhiều schema
 Tạo schema
◦ Logical view\Data Modeler\New\Schema
◦ Gán database cho schema
24

Data Model DiagramData Model Diagram
 Ngay khi schema được tạo, có thể tạo 1 lược
đồ mô hình Data ngay trong nó.
 Data Model diagram được dùng để thêm, chỉnh
sửa hay xem các bảng và các phần tử khác bên
trong mô hình data. Nó có cùng mục đích như
lược đồ Class trong mô hình object
 Mặc dù có thể thêm các phần tử trực tiếp ngay

trong browser, nhưng lược đồ mô hình data là
cách tốt nhât để mô tả 1 cách hình ảnh các
phần tử và mối quan hệ của chúng.
 Có thể tạo nhiều lược đồ mô hình data cho
mỗi schema.
 Tạo lược đồ mô hình data
Schema\Data Modeler\New\Data Model Diagram
25