BÀI GIẢNG ORM và UML

Trong UML, mặc định các thuộc tính attribute là bắt buộc mandatory và có giá... Loại quan hệ ORM Employee was born in Country được mô hình như thuộc tính birthcountry tr

Các phương pháp ngữ nghĩa để mô hình hóa

hệ thống thông tin xuất hiện ngày càng nhiều

• Hình ảnh "Yama" (Yet Another Modeling

Approach) theo nghĩa tiếng Nhật là

"Mountain"

Gần đây, UML được xem như 1 phương pháp

thích hợp để mô hình hóa CTUD

 Đã có đề xuất "the modeling wars are

over UML has won"

UML được ứng dụng chủ yếu trong thiết kế

mã chương trình hướng đối tượng

 Hiện nay UML cũng được dùng trong thiết kế

database nhưng chưa thay thế được phương

pháp ER Tuy nhiên trong tương lai khi phát

triển HT theo hướng đối tượng thì UML là 1

ngôn ngữ quan trọng để thiết kế database

Tương tự ER, UML sử dụng attributes, tuy số

lượng attribute có thể quá lớn nhưng dùng

attribute thì dễ mô hình được mối quan hệ

giữa các thực thể, ít bị ảnh hưởng khi thực thể thay đổi

 Cách tốt nhất để phát triển mô hình dữ liệu

bằng UML là “first do an ORM model and

then map it to UML”

No language is perfect, ORM cũng không

ngoại lệ

◦ UML cung cấp 1 loạt các ký hiệu để mô hình hóa

cả dữ liệu và qui trình (process)

◦ ORM hiện chỉ tập trung vào việc mô hình hóa dữ

liệu.

Ví dụ của 1 lược đố class UML

Lược đồ class mô tả các lớp Employee và Car và mối kết hợp giữa chúng.

 Tương ứng với quan hệ ORM Employee drives Car

Role "driver" phía bên trái mối kết hợp làm rõ ngữ nghĩa

 Mũi tên ở bên phải mối kết hợp để chỉ rằng

một điển hình của employee có thể truy xuất đến 1 điển hình car của nó Mối kết hợp này

chỉ liên quan đến việc thực thi và không chỉ ra ý niệm của mô hình nghiệp vụ

Bằng cách bỏ qua chi tiết, lược đồ class có

thể được dùng để phân tích ý niệm Khi dùng

theo cách này thì lược đồ class rất giống với

mô hình ER

 Nhưng có 1 sự khác biệt đáng kế nếu xét theo hướng OO

 Khác biệt gì??

Không có sơ đồ xác định (identification

schemas) trong class Với lập trình OO, các

đối tượng có thể được nhận biết thông qua

địa chỉ bộ nhớ, vì vậy UML không cần đến sơ

đồ này

 Nhưng nếu dùng để phân tích ý niệm thì cần

phải có sơ đồ tham chiếu hướng người dùng

UML cho phép thêm 1 số thuộc tính với các

ký hiệu không theo tiêu chuẩn để khai báo

cách nhận biết và ràng buộc của class

◦ “{P}” để chỉ tham chiếu hay dùng (preferred

reference )

◦ "{ Un }" để chỉ tính duy nhất (n > 0), với n là

số trường hợp có cùng nghĩa khi cùng ràng buộc

U được áp dụng cho 1 tổ hợp các thuộc tính.

Lược đồ class với các ký hiệu không theo tiêu chuẩn để chỉ khóa Primary key và ràng buộc

duy nhất

ORM chia object thành 2 loại: entities

(non-lexical objects) và values ((non-lexical objects)

và bắt buộc mỗi entity phải được xác định bởi một sơ đồ tham chiếu (reference scheme )

ORM sử dụng "object", "entity", và "value"

để chỉ "object instance", "entity instance“và "value instance“

• Các entities có thể được tham chiếu theo

nhiều cách, và có thể thay đổi trạng thái

(state) theo thời gian

UML chia các instances thành objects và data values

• Các UML objects tương ứng với các ORM

entities Các UML data values tương ứng với

các ORM values, chúng đều là hằng số

• Các loại entity trong UML được gọi là classes và các loại value thì được gọi là data types

• "object" có nghĩa là 1 "object instance", chứ

không phải là "object type".

• Mối điển hình quan hệ (relationship instance)

trong UML được gọi là 1 link, và loại quan hệ

được gọi là một association

Trong UML, mặc định các thuộc tính

(attribute) là bắt buộc (mandatory) và có giá

Attribute multiplicity constraint

– Trong mô hình ORM, birth country, social security

number, hay passport number đều là tùy chọn Trong

UML tùy chọn này được thể hiện thông qua việc thêm

multiplicity [0 1] vào mỗi thuộc tính tương ứng

• Uniqueness constraints (UC):

– Trong ORM, các UC dùng để chỉ mỗi employee number, social security number, và passport number chỉ tham chiếu duy nhất đến 1 employee mà thôi

– UML không có ký hiệu chuẩn để chỉ "attribute

uniqueness constraints", vì vậy nó được bổ sung bởi ký

hiệu do ta tự quy định lấy, chẳng hạn {P} và {Un }

UML cũng không có ký hiệu để chỉ ràng buộc

loại trừ (inclusive-or constraint), ràng buộc

này có thể diễn tả bằng note đính kèm, hay

đặt ràng buộc vào {}

Loại quan hệ ORM Employee was born in

Country được mô hình như thuộc tính

birthcountry trong lược đồ class UML

 Nếu sau này khi cần lưu trữ lại phân bố của

country thì cần phải đưa vào lớp Country và

để làm rõ kết nối giữa birthcountry và

Country có thể cần phải biến đổi thuộc tính

birthcountry thành mối kết hợp giữa 2 class

Employee và Country

 ORM tránh được sự bất ổn ngữ nghĩa này vì

nó luôn sử dụng quan hệ thay vì dùng thuộc

tính

Có giải thuật để phát triển lược đồ UML và ER từ lược đồ ORM

 Các giải thuật này gán các mức độ quan

trọng khác nhau vào các loại đối tượng tùy

thuộc vào role và các ràng buộc

 Mức độ quan trọng này có thể thay đổi theo

thời gian khi ta khám phá được nhiều hơn mô hình tổng thể và bản thân nghiệp vụ cũng bị

thay đổi theo thời gian

 Thuộc tính đa trị “sports“ trong UML được

chỉ ra bằng ràng buộc "[0 *]" (một người

có thể chơi nhiều môn thể thao khác nhau hoặc không chơi môn nào)

 Trong sơ đồ ORM tương đương, loại quan

hệ many:many được dùng thay cho thuộc tính đa trị sports.

Class Flag dùng để lưu

trữ nickname và màu cờ của các quốc gia

 Các ràng buộc:

nickname

 Một UC phụ khác cũng

cần xác định là mỗi

nickname tham chiếu

nhiều nhất đến một flag

Không chỉ mỗi nicknames phải là duy nhất

đối với mỗi flag mà mỗi phần tử trong mỗi tập hợp cũng phải duy nhất Mối ràng buộc phức

này được xác định trong UML dưới dạng 1

note đính kèm (attached note)

Thuộc tính Nickname: miền giá trị là một loại

dữ liệu nào đó, có thể là string

 Thuộc tính countries hay colors:

◦ Nếu không cần lưu trữ thêm thông tin , có thể

chọn string như miền giá trị (domain)

◦ Nếu muốn có thêm thông tin để dùng sau này,

tốt hơn là nên dùng class Country và Color để

xác định domain cho nó

UML cho phép ta mô hình 1 tính chất nào đó

như một attribute hay một association Để

phân tích ý niệm thì dùng association thường có nhiều thuận lợi hơn so với attributes, đặc

biệt là với thuộc tính đa trị

◦ Dễ mô hình hóa và tạo phân bổ cho association

hơn.

◦ Cho phép diễn tả các ràng buộc có dạng "role

played by the attribute" ở dạng chuẩn hơn là phải dùng các mở rộng không đúng tiêu chuẩn

Nếu dùng association Flag is of Country

thì ràng buộc each country has at most one flag có thể đưa vào thông qua ràng

buộc "0 1" đặt bên trái mối kết hợp này

 Dùng associations thì ổn định hơn

attributes Thay vì mô hình 1 tính chất

thành 1 attribute, đầu tiên thay thế

attribute này thành 1 association Sau đó

dù là UML hay ORM đều đễ dàng tạo ra đối tượng từ một association và đính kèm vào nó 1 số chi tiết mới

Khảo sát association Employee plays Sport Nếu cần lưu trữ lại skill level cho một lần chơi nào đó play, ta có thể đối tượng hóa

association này thành Play, và đưa thêm vào

1 loại quan hệ: Play has SkillLevel Trong mô

hình UML việc này được thực hiện dễ dàng

nếu play được mô hình như 1 association

 Trong ví dụ thì play được mô hình như

attribute sports , thì cần thay thế thành 1

association tương đương trước khi thêm chi

tiết mới skill level vào

Khi truy vấn đến các thuộc tính đa trị thì sẽ

phức tạp hơn thuộc tính đơn trị

 Ví dụ: so sánh các truy vấn Q1,

Thuộc tính đa trị (multivalued attribute) nên

tránh dùng trong mô hình phân tích Tuy

nhiên vẫn có thể sử dụng thuộc tính đa trị

trong thực thi sau này

UML dùng thuộc tính Boolean để chỉ mối

quan hệ 1 chiều (unary relationship)

 Với các quan hệ 2 chiều trở lên (association):

◦ Thường được đặt tên bắt đầu bằng 1 ký tự chữ

hoa

◦ Các associations 2 chiều được ký hiệu là đường

thẳng nối giữa 2 class.

◦ Association role được ký hiệu như đầu cuối của

đường thẳng (line end) thay vì là các box

Trong UML, tên association là tùy chọn nhưng tên role là bắt buộc Nếu không đặt tên role

thì tên lớp cũng được xem là tên role Nếu có

2 hay nhiều role cho cùng 1 class thì các role

phải có các tên khác nhau để phân biệt

 Trong ORM, các predicate thuận và ngược cần được chỉ rõ, hoặc chỉ cần chỉ rõ 1 trong 2 loại Tên role là tùy chọn và được đặt trong ngoặc

vuông

Association từ 3 ngôi trở lên được ký hiệu

như 1 diamond và nối đến các class bằng

các đường thẳng

Thường không có ký hiệu chỉ hươńg đọc

(reading direction indicator), nên các lược đồ class của UML không được dùng để giao tiếp

trong dạng câu nói thông thường Lược đồ

class cũng không thuận tiện trong việc tạo

phân bố cho các association nếu không đặt

tên role cho các cột tương ứng trong bảng

phân bố

Trong lược đồ UML, cả hai cặp Room-HourSlot và HourSlot-Activity đều là duy nhất Trong

ORM là các UC tương ứng

Các ký hiệu ràng buộc multiplicity của UML

thì phong phú hơn của ER Tuy nhiên có nhiều trường hợp ký hiệu multiplicity của UML

không thể diễn đạt được ràng buộc của role

bắt buộc hay ràng buộc thường xuyên tối

thiểu lớn hơn 1 (minimum frequency

constraint above 1)

 Các ký hiệu ràng buộc của ORM có thể diễn

đạt được bất kỳ ràng buộc nào trên các role

hay các predicate nhiều ngôi Vì vậy ORM

phong phú hơn trong việc diễn đạt ràng buộc

Vì UML cố đưa cả hai loại ràng buộc bắt buộc và

duy nhất vào cùng 1 ký hiệu nên không thể diễn

đạt được cho từng hoạt động book phòng  buộc phải đưa thêm 1 note vào lược đồ

 Lược đồ ORM tương ứng có thể diễn đạt được

Nguyên nhân của việc khó diễn đạt ràng buộc trong UML là do đính kèm ràng buộc

multiplicity tối thiểu vào role mà không qua 1 role trung gian

 Với cùng lý do này, UML không thể diễn đạt

được các ràng buộc thường xuyên (frequency constraints )khác của ORM

In general, given any n-ary (n > 2)

association, if an ORM mandatory or

frequency constraint applies to at

least 1 and at most n - 2 roles, this

cannot be captured by a UML

multiplicity constraint.

Cả UML và ORM đều cho phép đối tượng hóa

các mối kết hợp (association) thành các loại

đối tượng

◦ Trong UML: tạo thành các association class nhưng

cần phải giữ nguyên tên trong association gốc lúc

đầu và association class tương ứng

◦ Trong ORM: tạo thành các objectified association

hay các loại nested object, không bắt buộc mối kết

hợp và đối tượng lồng nhau phải cùng tên (1 cụm

động từ được đối tượng hóa thành cụm danh từ, nên cả hai đều có thể phát biểu thành câu có đủ ngữ

nghĩa thông thường)

Trong UML, thuộc tính period chỉ ra một person

mất bao nhiêu lâu để viết 1 paper

 Trong ORM, Writing được đánh dấu độc lập bởi ký

hiệu "!“ để chỉ ra đối tượng writing có thể tồn tại

một cách độc lập không cần quan tâm đến việc có lưu trữ lại period hay không ORM hiển thị Period

Ràng buộc Set-comparison bao gồm:

◦ Ràng buộc tập con (subset)

◦ Ràng buộc ngang bằng (equality)

◦ Ràng buộc quan hệ loại trừ (exclusion

relationship)

◦ giữa các phân bố của các role khác nhau

 UML cho phép tạo các ràng buộc subset giữa các mối kết hợp bằng cách đính kèm nhãn

ràng buộc "{ subset }" kế bên mũi tên đứt

nét nối giữa các mối kết hợp (association)

Ràng buộc subset “any person who chairs

a committee must be a member of that

committee”

Trong ORM, ràng buộc equality giữa hai quan

hệ có thể tích hợp (compatible), là cách viết

tắt của 2 ràng buộc subset theo 2 chiều

ngược nhau, được ký hiệu "=“ khoanh tròn

Phân bổ ứng với mỗi ràng buộc subset phải

bằng nhau

 Nếu 2 role của cùng 1 object đều bắt buộc thì giữa chúng sẽ ngầm định có 1 ràng buộc

equality

 UML không có ký hiệu dành cho ràng buộc

equality, có thể dùng note để chú thích ràng

buộc loại này

Nếu đo đuợc áp lực máu về tim (systolic) thì

cũng sẽ đo được áp lực máu đi từ tim ra

(diastolic) và ngược lại

Trong UML, có 1 ký hiệu để chỉ ràng buộc

exclusive-or: mỗi điển hình (instance) của 1 class phải có chính xác 1 role trong số 1 tập các role khác nhau (set of alternatives) Ký hiệu "{xor}" đặt bên cạnh đường đứt nét nối các association với nhau

 Trong ORM, ký hiệu tương ứng sẽ là 1 tổ hợp vuông góc của ràng buộc inclusive-or (chấm được khoanh tròn) và ràng buộc exclusion (X được khoanh tròn)

Mỗi account được dùng bởi 1 person hay 1

corporation nhưng không thể cùng lúc cho cả hai

Cả hai UML và ORM đều hỗ trợ kiểu con

(subtyping), mỗi điển hình kiểu con cũng là 1 điển hình của siêu kiểu (supertype)

 Cho 2 loại đối tượng A và B, A là subtype của

B nếu với mỗi trạng thái của database, phân

bố của A được bao gồm trong phân bố của B

 A là proper subtype của B nếu và chỉ nếu A là subtype của B và có thể tồn tại 1 trạng thái

sao cho phân bố của B chứa 1 điển hình

không có trong A

 Viết tắt "subtype" thay cho "proper subtype"

Trong cả UML và ORM, chuyên biệt hóa

(specialization) là quá trình giới thiệu các

subtypes, và tổng quát hóa

(generalization) là quá trình ngược lại để

giới thiệu một supertype

 Cả UML và ORM đều cho phép sử dụng kế thừa đơn (single inheritance) cũng như đa kế thừa (multiple inheritance) (một

subtype có nhiều hơn 1 supertype)

◦ Ví dụ đa kế thừa: AsianWoman có thể là

subtype của cả AsianPerson và Woman.

Trong UML, "subclass" và "superclass" đồng nghĩa với "subtype" và "supertype", tổng

quát hóa không chỉ áp dụng cho class mà cho cả interfaces, use case actors, và

packages