การออกแบบฐานข้อมูล อีอาร์โมเดล

ปรับปรุง : 2563-05-01 (sdlc)
SDLC

การวิเคราะห์ระบบ (System Analysis) คือ การศึกษาแยกแยะงานออกเป็นส่วนย่อย/ระบบย่อย เพื่อทำความเข้าใจปัญหาที่เกิดขึ้นในระบบงานที่ใช้อยู่ แล้วออกแบบส่วนย่อยที่มีปัญหาขึ้นมาใหม่ หรือปรับปรุงแต่ละส่วนให้มีประสิทธิภาพยิ่งขึ้น

จากนั้นนำส่วนย่อยทั้งหมดมารวมกันเป็นระบบใหม่ (New System) ถ้าระบบใหม่ยังไม่ถูกนำไปติดตั้งใช้งานก็จะเรียกระบบที่ใช้อยู่ว่า ระบบปัจจุบัน (Current System) แต่ถ้าระบบใหม่ได้ถูกติดตั้งและใช้งาน จะเรียกระบบปัจจุบันที่เคยใช้ว่า ระบบเก่า (Old System)

การออกแบบระบบ (System Design) คือ การทำความเข้าใจส่วนย่อยที่ได้รับจากการวิเคราะห์ระบบมาพัฒนาเปลี่ยนแปลงอย่างเป็นรูปธรรม เพื่อแก้ปัญหาเดิมหรือปรับปรุงให้ดีขึ้น แล้วนำส่วนย่อยมารวมกัน โดยคำนึงถึงองค์ประกอบการออกแบบระบบที่เกี่ยวข้องเชิงบูรณาการ ทั้งส่วนนำเข้า (Input) ส่วนประมวลผล (Process) ส่วนแสดงผล (Output) และส่วนจัดเก็บข้อมูล (Storage) รวมถึงรูปแบบทางกายภาพ (Physical Model) ได้แก่ ฮาร์ดแวร์ (Hardoware) ซอฟต์แวร์ (Software) ผู้คนที่เกี่ยวข้อง (Peopleware)

การวิเคราะห์และออกแบบระบบ (System Analysis and Design) คือ การศึกษาแยกแยะงานออกเป็นส่วนย่อย เพื่อทำความเข้าใจปัญหาที่เกิดขึ้นในระบบงานที่ใช้อยู่ แล้วออกแบบพัฒนาส่วนย่อยใหม่ เพื่อนำมาประกอบขึ้นเป็นระบบใหม่ที่มีความสมบูรณ์ โดยคำนึงถึงการออกแบบฮาร์ดแวร์ ซอฟต์แวร์ กระบวนการทำงาน เครือข่าย โครงสร้างข้อมูล อัลกอริทึม การทดสอบ เวลาในการประมวลผล การจัดทำรายงาน และหน้าจอในส่วนติดต่อกับผู้ใช้ระบบ

ขั้นตอนการวิเคราะห์และออกแบบระบบ หรือ วงจรชีวิตการพัฒนาระบบ (System Development Life Cycle = SDLC)
1. การระบุระบบ (System Identification and Selection)
2. การวางแผน (System Initiation and Planning)
3. การวิเคราะห์ (System Analysis)
4. การออกแบบ (System Design)
5. การติดตั้งใช้งาน (System Implementation)
6. การบำรุงรักษา (System Maintenance)
ระบบฐานข้อมูล (Database System) ระบบฐานข้อมูล (Database System) คือ การรวมข้อมูลที่เกี่ยวข้องสัมพันธ์กันเข้าด้วยกัน (Integrate) มีการจัดกลุ่มข้อมูลเก็บอยู่ในรูปตาราง (Grouping) เชื่อมโยงตารางทั้งหมดเข้าด้วยกัน (Share) เพื่อลดความซ้ำซ้อนในการจัดเก็บข้อมูล (Non Redundancy)
ระบบ (System) ประกอบด้วย 1)วัตถุประสงค์ (Objective) 2)ปัจจัยนำเข้า (Input) 3)กระบวนการ (Process) และ 4)ผลผลิต (Output)
การออกแบบฐานข้อมูลด้วย E-R model เป็นเพียงวิธีหนึ่งที่ช่วยในการออกแบบฐานข้อมูล แต่วิธีนี้ได้รับความนิยมอย่างมาก นำเสนอโดย Peter ซึ่งวิธีการนี้อยู่ในระดับ Conceptual level และมีหลักการคล้ายกับ Relational model เพียงแต่ E-R model แสดงในรูปแบบกราฟฟิก บางระบบจะใช้ E-R model ได้เหมาะสมกว่า แต่บางระบบจะใช้ Relational model ได้เหมาะสมกว่าเป็นต้น ซึ่งแล้วแต่การพิจารณาของผู้ออกแบบว่าจะเลือกใช้แบบใด (Relational model คือตารางข้อมูลที่มีความสัมพันธ์กัน)
ระบบ (System) หมายถึง ขั้นตอนการปฏิบัติงานที่มีการกำหนดอย่างชัดเจนว่าต้องทำอะไรบ้าง เพื่อให้ได้ผลออกมาตามที่ต้องการ ขั้นตอนการปฏิบัติงานจะต้องปรากฎให้ทราบโดยทั่วกันไม่ว่าจะอยู่ในรูปของเอกสารหรือสื่ออิเล็กทรอนิกส์ หรือโดยวิธีการอื่น ๆ องค์ประกอบของระบบ ประกอบด้วย ปัจจัยนำเข้า กระบวนการ ผลผลิต และข้อมูลป้อนกลับ ซึ่งมีความสัมพันธ์เชื่อมโยงกัน #
+ การฝึกปฏิบัติเกี่ยวกับระบบฐานข้อมูลในอินเทอร์เน็ต
+ MySQL
+ MS Access
+ ที่ sqlfiddle.com มีบริการให้ทดสอบใช้คำสั่ง SQL ได้
+ ที่ w3schools.com มีบริการให้ทดสอบใช้คำสั่ง SQL ได้
+ ที่ sqlzoo.net มีบริการให้ทดสอบใช้คำสั่ง SQL ได้
    สารบัญ
  1. สถาปัตยกรรมฐานข้อมูล 3 ระดับ
  2. ขั้นตอนเกี่ยวกับการออกแบบฐานข้อมูล
  3. ER model (Entity-Relationship Model)
  4. ขั้นตอนการเขียน ER model
  5. ขั้นตอนการ Normalization
  6. การ denormalization
  7. แนะนำเว็บ (Web guides)
  8. เอกสาร และบุคคลอ้างอิง
  9. แบบฝึกหัด
ER ของระบบทะเบียนโดย ชาญนรงค์ (นักศึกษาโยนกรุ่นที่ 12) [Diagram]
ER ของระบบเก็บภาพถ่าย โดย Jeff Ullman [Diagram]
1. สถาปัตยกรรมฐานข้อมูล(Database architecture) 3 ระดับ(Three-level architecture) 1.1 ระดับภายนอก (External level)
มาจากแบบฟอร์มเอกสาร ว่ามีอะไรในเอกสารบ้าง หรือจากผู้ใช้ที่แต่ละคน
เป็นการรวบรวมข้อมูลอย่างง่าย ๆ จากผู้ใช้ เพื่อให้กับนักวิเคราะห์นำไปศึกษา
ผู้ใช้คนที่หนึ่ง : (รหัส, ชื่อ)
ผู้ใช้คนที่สอง : (รหัส, ที่อยู่)
1.2 ระดับความคิด (Conceptual level)
1.3 ระดับภายใน (Internal level)
ตีความในระดับการจัดเก็บข้อมูลจริง เป็นหน้าที่ของผู้ออกแบบอย่างแท้จริง
struct person{
  int id;
  char name[20];
  char address[20]
} index id;
ตัวอย่างของ Relation schema ของ Northwind
  1. Categories (CategoryID, CategoryName, Description, Picture)
  2. Customers (CustomerID, CompanyName, ContactName, ContactTitle, Address, City, Region, PostalCode, Country, Phone, Fax)
  3. Employees (EmployeeID, LastName, FirstName, Title, BirthDate, HireDate, Address, City, Region, PostalCode, Country, HomePhone, Extension, Photo, Notes, ReportsTo)
  4. Products (ProductID, ProductName, SupplierID, CategoryID, QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, ReorderLevel, Discontinued)
  5. Shippers (ShipperID, CompanyName, Phone)
  6. Suppliers (SupplierID, CompanyName, ContactName, ContactTitle, Address, City, Region, PostalCode, Country, Phone, Fax, Homepage)
  7. Orders (OrderID, CustomerID, EmployeeID, OrderDate, RequiredDate, ShippedDate, ShipVia, Freight, ShipName, ShipAddress, ShipCity, ShipRegion, ShipPostalCode, ShipCountry)
  8. Order Details (OrderID, ProductID, UnitPrice, Quantity, Discount)

    ตารางข้างล่างนี้คือ ตารางแสดงความสัมพันธ์ที่ใช้โปรแกรม Microsoft access สร้างขึ้น
2. ขั้นตอนเกี่ยวกับการออกแบบฐานข้อมูล 2.1 เปลี่ยนความต้องการของผู้ใช้เป็น ER model หรือ Relational model
   2.1.1 โมเดลแบบ ER model (Entity-Relationship Model)
   - เอ็นติตี้ (Entity)
   - แอททริบิวท์ (Attribute)
   - ความสัมพันธ์ระหว่างเอ็นติตี้ (Relationship)
   - ดีกรีของความสัมพันธ์ (Degree of a relation)
   2.1.2 โมเดลเชิงสัมพันธ์ (Relational model)
   - รีเลชัน (Relation) หรือ Table หรือ file
   - ทูเพิล (Tuple) หรือ Row หรือ Record
   - แอททริบิวท์ (Attribute) หรือ Column หรือ Field
2.2 การทำนอร์มัลไลซ์ (Normalization)
2.3 กำหนดคุณสมบัติของเขตข้อมูลแต่ละตัว
3. ER model (Entity-Relationship Model) :: เสนอครั้งแรกโดย ปีเตอร์(Chen,1976 - 2519) เป็นเครื่องมือนำเสนอโครงสร้างของฐานข้อมูลใน ระดับความคิด(Conceptual level) ออกมาในลักษณะของแผนภาพ(Diagram) ที่ง่ายต่อความเข้าใจ เพื่อสื่อความหมายระหว่างนักออกแบบฐานข้อมูล และผู้ใช้ เกี่ยวกับ ความสัมพันธ์ของเอนติตี้(Entity) กับเอนติตี้(Entity) และเอนติตี้(Entity) กับ แอททริบิวท์(Attibute)
From: http://www.utexas.edu/cc/database/datamodeling/dm/erintro.html
The Entity-Relationship (ER) model was originally proposed by Peter in 1976 [Chen76] as a way to unify the network and relational database views. Simply stated the ER model is a conceptual data model that views the real world as entities and relationships. A basic component of the model is the Entity-Relationship diagram which is used to visually represents data objects. Since Chen wrote his paper the model has been extended and today it is commonly used for database design For the database designer, the utility of the ER model is:
- It maps well to the relational model. The constructs used in the ER model can easily be transformed into relational tables.
- It is simple and easy to understand with a minimum of training. Therefore, the model can be used by the database designer to communicate the design to the end user.
- In addition, the model can be used as a design plan by the database developer to implement a data model in a specific database management software.

From: http://itprojmngt.8m.net/softdev/analysis/erd/erd.html
The goal of Entity Relationship Modeling Technique is to discover and represent the relations between groups of information elements. The method will list the information which is essential for the application and/or organization, structure and describe this information. The results will serve to design the databases. The resulting drawing is never finished. It will evolve together with the information which is managed by the application or/and which serves the business purposes.

ส่วนประกอบของ ER model
- เอ็นติตี้ (Entity)
- แอททริบิวท์ (Attribute)
- ความสัมพันธ์ระหว่างเอ็นติตี้ (Relationship)
- ดีกรีของความสัมพันธ์ (Degree of a relation)

ขั้นตอนการเขียน ER model
3.1 สร้าง entity ขึ้นมาจากความต้องการของผู้ใช้
3.2 สร้างความสัมพันธ์(Relation) ระหว่าง entity
3.3 พิจารณา key ของแต่ละ entity
3.4 พิจารณาคุณสมบัติของ entity แต่ละตัว
4. ขั้นตอนการเขียน ER model 4.1 กำหนด Entity type โดยกำหนดมาจากความต้องการของผู้ใช้ระบบ ว่าจะให้มี Entity สำหรับเก็บข้อมูลอะไรบ้าง
เอนติตี้(Entity) อาจเรียกว่า file หรือ table
4.1.1 Strong entity คือเกิดขึ้นด้วยตนเองไม่ขึ้นกับ entity ใด เช่น นักศึกษา หรืออาจารย์ หรือสินค้า เป็นต้น
4.1.2 Weak entity คือขึ้นโดยอาศัย entity อื่น เช่น เกรดเฉลี่ย ที่มาจากแฟ้มผลการเรียน หรือ แฟ้มลงทะเบียน หรือ แฟ้มสั่งซื้อ เป็นต้น
:: สิ่งต่าง ๆ ที่ผู้ใช้งานฐานข้อมูลจะต้องยุ่งเกี่ยวด้วย เช่น คน แผนก ประเภท การสั่งซื้อ เป็นต้น
Entities are the principal data object about which information is to be collected. Entities are usually recognizable concepts, either concrete or abstract, such as person, places, things, or events which have relevance to the database. Some specific examples of entities are EMPLOYEES, PROJECTS, INVOICES. An entity is analogous to a table in the relational model.

4.2 กำหนดความสัมพันธ์ (Relationship type) ที่เกิดขึ้นระหว่าง entity ในลักษณะของกริยา
5. ขั้นตอนการ Normalization 5.1 เปลี่ยนตารางที่ยังไม่เคย Normalization เป็น First Normal Form หรือ 1NF
วิธีพิจารณา คือ แยกข้อมูลเป็นระเบียน โดยไม่มีการจัดกลุ่ม
ตารางที่ไม่ผ่านการ normalization
orderid
305		 orderdate
31/01/47		 productid
432
455
467		 quan
20
2
1
ตารางที่ผ่านการ normalization ในระดับ 1NF
orderid orderdate productid quan
305 31/01/47 432 20
305 31/01/47 455 2
305 31/01/47 467 1


5.2 เปลี่ยนจาก 1NF เป็น 2NF(Second Normal Form) คือการเปลี่ยนตารางที่มีปัญหา 4 ประการ
วิธีพิจารณาเปลี่ยน 1NF เป็น 2NF คือ ไม่มี non key ตัวใด ไม่สัมพันธ์กับ primary key (ให้พิจารณาเฉพาะ non key และ primary key)
สิ่งที่ได้จากตาราง 1 ตาราง จะแตกออกมาเป็นหลายตาราง
   5.2.1 แก้ไขข้อมูล ต้องแก้หลายระเบียน
   5.2.2 มีข้อมูลเดียวกันในหลายระเบียน อาจขัดแย้งกันได้
   5.2.3 การเพิ่มข้อมูลทำได้ยาก
   5.2.4 การลบข้อมูลทำได้ยาก
ท่านลองพิจารณา Schema ของตารางนี้ว่าจะแยกได้กี่ตาราง
จาก orderid,custid,custname,date,proid,proname,price,quantity,categoryid,categoryname
เป็น orders (orderid,custid,custname,date,proid,proname,price,quantity)
เป็น categories (categoryid,categoryname)
เหตุที่แยก categories ออกมา เพราะ categoryid ไม่สัมพันธ์กับ orderid แต่สัมพันธ์กับ proid โดยตรง จึงต้องแยกออกมา

5.3 เปลี่ยนจาก 2NF เป็น 3NF(Third Normal Form) คือแก้ปัญหายังไม่หมด อาจยังมีข้อมูลที่มีปัญหาอีก จึงต้องทำ 3NF
วิธีพิจารณาเปลี่ยน 2NF เป็น 3NF คือ ไม่มี non key ตัวใด ขึ้นอยู่กับ non key ตัวอื่นใน entity เดียวกัน (ให้พิจารณาเฉพาะ non key และ non key)
จาก orders (orderid,custid,custname,date,proid,proname,price,quantity)
เป็น orders (orderid,custid,date)
เป็น customers (custid,custname)
เป็น order details (orderid,proid,price,quantity)
เป็น products (proid,proname)
ตัวอย่าง 5.1 ตารางที่ยังไม่ทำ normalization (จากเอกสารของผู้ใช้ที่ส่งให้นักวิเคราะห์)
เป็นตารางการสั่งซื้อ ให้ท่านลองนำไปทำ normalization
orderid
301		 orderdate
15/12/46		 productid
401
402		 quan
2
5
302 16/12/46 402
405
406		 4
4
1
ตัวอย่าง 5.2 ตารางที่ยังไม่ทำ normalization (จากเอกสารของผู้ใช้ที่ส่งให้นักวิเคราะห์)
เป็นตารางเงินเดือน ให้ท่านลองนำไปทำ normalization
saleid
101




 salesalary
2000		 saleposition
sale		 custid
201
202
203
204		 custname
tom
dang
boy
girl
ตัวอย่าง 5.3 ใบเสร็จ 2 ใบ เลขที่ A0001 และ A0002 (ให้ท่านลองนำไปทำ normalization)
ตัวอย่างนี้ได้รับการเสนอแนะจาก sudomvon@minebea.co.th
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
                              Invoice No.:      A0001
                              Date:        24/10/2004
Sold to: ABC company
Item                    Quantity    UnitPrice   Amount
Pen                       50        3           150
Book                     100        5           500
Ruler                     20        2            40
                                    Total       690
<hr color="black">
                              Invoice No.:      A0002
                              Date:       24/10/2004
Sold to: XYZ company
Item                    Quantity    UnitPrice   Amount
Pen                     100         3           300
Book                    120         5           600
Ruler                    50         2           100
                                    Total      1000
การทำ Normalization ของตัวอย่าง 5.3 (ได้รับคำแนะนำจาก อ.อมรทิพย์ rung@yonok.ac.th)
?
1
2
3
4
5
6
7
8
9
การเริ่มต้นทำ normalization ต้องนำข้อมูลมาสร้าง <b>ตารางเริ่มต้น</b> ซึ่งเป็นขั้นตอนก่อนการทำ 1NF
โดยไม่เขียน amount และ total เพราะเป็นค่าที่เกิดจากการคำนวณเท่านั้น
<font face="fixedsys"><u>ตาราง temp</u>
A0001,24/10/2004,ABC  company,Pen,50,3
A0001,24/10/2004,ABC  company,Book,100,5
A0001,24/10/2004,ABC  company,Ruler,20,2
A0002,24/10/2004,XYZ  company,Pen,100,3
A0002,24/10/2004,XYZ  company,Book,120,5
A0002,24/10/2004,XYZ  company,Ruler,50,2</font>
?
1
2
3
4
5
6
7
8
9
10
<u><b>การทำ 1NF ของ ตัวอย่าง 5.3</b></u><br>นำตารางเริ่มต้นมาจัดการเรื่อง multivalue เช่น คนชอบกินหลายอย่าง หรือการเพิ่ม key ประกอบข้อมูลที่อาจซ้ำ
ตัวอย่างนี้เพิ่มรหัสลูกค้า และรหัสสินค้า เป็น key เพราะคิดว่า ชื่อลูกค้า และชื่อสินค้า อาจมีโอกาสซ้ำกันได้ และไม่เหมาะที่จะเป็น key<font face="fixedsys">
ตาราง <u>tempoforder</u>
<u>A0001</u>,24/10/2004,101,ABC  company,<u>201</u>,Pen,50,3
A0001,24/10/2004,101,ABC  company,202,Book,100,5
A0001,24/10/2004,101,ABC  company,203,Ruler,20,2
A0002,24/10/2004,102,XYZ  company,201,Pen,100,3
A0002,24/10/2004,102,XYZ  company,202,Book,120,5
A0002,24/10/2004,102,XYZ  company,203,Ruler,50,2
</font>
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<font color="#008000"><u><b>การทำ 2NF ของ ตัวอย่าง 5.3</b></u><br>แยกตาราง tempoforder เป็นหลายตาราง และทุกตารางมี primary key ที่มีการตรวจสอบการขึ้นตรงอย่างถูกต้อง<font face="fixedsys">
<font face="microsoft sans serif" color="red">primay key คือ รหัสใบสั่งซื้อ</font>
ตาราง invoid_1
<u>A0001</u>,24/10/2004,101,ABC  company
A0002,24/10/2004,102,XYZ  company
<font face="microsoft sans serif" color="red">primay key คือ รหัสใบสั่งซื้อ และรหัสสินค้า</font>
ตาราง invoid_2
<u>A0001,201</u>,50,3
A0001,202,100,5
A0001,203,20,2
A0002,201,100,3
A0002,202,120,5
A0002,203,50,2
<font face="microsoft sans serif" color="red">ตาราง product เพราะราคาขึ้นกับรหัสสินค้า
primary key คือ รหัสสินค้า</font>
ตาราง product
<u>201</u>,Pen,3
202,Book,5
203,Ruler,2
</font>
</font>
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<u><b>การทำ 3NF ของ ตัวอย่าง 5.3</b></u><font face="fixedsys">
<font face="microsoft sans serif" color="red">ตาราง invoid_1 เพราะชื่อลูกค้าไม่ขึ้นกับรหัสใบสั่งซื้อ จึงต้องแยกไปทำตาราง customer
primay key คือ รหัสใบสั่งซื้อ</font>
ตาราง invoid_1
<u>A0001</u>,24/10/2004,101
A0002,24/10/2004,102
<font face="microsoft sans serif" color="red">ตาราง customer เพราะชื่อลูกค้าไม่ขึ้นกับ รหัสใบสั่งซื้อ แต่ขึ้นกับรหัสลูกค้า
primay key คือ รหัสลูกค้า</font>
ตาราง customer
<u>101</u>,ABC  company
102,XYZ  company
<font face="microsoft sans serif" color="red">primay key คือ รหัสใบสั่งซื้อ และรหัสสินค้า เพราะ ปริมาณ และราคาต้องขึ้นกับ key 2 ตัวนี้</font>
ตาราง invoid_2
<u>A0001,201</u>,50,3
A0001,202,100,5
A0001,203,20,2
A0002,201,100,3
A0002,202,120,5
A0002,203,50,2
<font face="microsoft sans serif" color="red">ตาราง product เพราะราคาขึ้นกับรหัสสินค้า
primary key คือ รหัสสินค้า</font>
ตาราง product
<u>201</u>,Pen,3
202,Book,5
203,Ruler,2
</font>
ตารางความสัมพันธ์ (Relational Table)
Computer Hardware Information System Management ของ อ.ถนอม (thanom.net)
6. การ Denormalization

    Denormalization : The opposite of data normalization (almost). In a denormalized database, some duplicated data storage is allowed. The benefits are quicker data retrieval and/or a database structure that is easier for end-users.
    Denormalization the technique of placing normalized data in a physical location that optimizes the performance of the system
      เว็บไซต์เกี่ยวกับ denormalization
    1. http://www.oracledbaexpert.com/oracle/papers/Denormalization.htm ละเอียดมาก พร้อมภาพประกอบ
    2. http://www.olap.it/Articoli/THE%20DENORMALIZATION%20SURVIVAL%20GUIDE.htm or http://www.tdan.com/i021ht03.htm
    3. http://www.orafaq.net/glossary/faqglosd.htm Dictionary จาก oracle ละเอียดดีมาก Author: Frank Naud
    4. http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/en-us/part5/c1761.mspx
      Data warehouses support business decisions by collecting, consolidating, and organizing data for reporting and analysis with tools such as online analytical processing (OLAP) and data mining. Although data warehouses are built on relational database technology, the design of a data warehouse database differs substantially from the design of an online transaction processing system (OLTP) database.
7. แนะนำเว็บ (Web guides)
  1. http://www-db.stanford.edu/~ullman/fcdb/hernandez/PDA1.htm
  2. http://www.umr.edu/~madrias/cs304-01.html
  3. http://www.cs.toronto.edu/~jm/340S/PDF6/ERModel.pdf
  4. http://www.umsl.edu/~sauter/analysis/analysis_links.html รวม link System analysis ที่ยอดเยี่ยม
  5. http://www.cs.sfu.ca/CC/354/zaiane/material/notes/contents.html เรื่อง database ละเอียดดีมาก
  6. http://www.umsl.edu/~sauter/analysis/er/er_intro.html
  7. http://www.cs.tcd.ie/courses/baict/baim/jf-im/6ERtoRel.pdf มีภาพและคำอธิบายนิดหน่อยเกี่ยวกับระบบเกรด
  8. http://www.utexas.edu/cc/database/datamodeling/index.html ให้รายละเอียดที่ดีมาก แต่ภาพ er ไม่เหมือนในหนังสือ
  9. http://itprojmngt.8m.net/softdev/analysis/erd/erd.html
  10. http://kogs-www.informatik.uni-hamburg.de/~haarslev/publications/avitvl96/node3.html
  11. http://sysdev.ucdavis.edu/WEBADM/document/td_entityrel-guidelines.htm
  12. http://www2.bus.orst.edu/faculty/brownc/lectures/db_tutor/relational_model.htm
  13. http://www.doc.mmu.ac.uk/online/SAD/T06/erd1.htm
  14. http://webster.cs.uga.edu/~vuppula/index1.html
8. เอกสาร และบุคคลอ้างอิง
  1. ระบบฐานข้อมูล (Database system) [ผศ.สมจิตร อาจอินทร์ และงามนิจ อาจอินทร์]
  2. เอกสารประกอบการสอน วิชาการวิเคราะห์ และออกแบบระบบ 4122502 [โปรแกรมวิชาวิทยาการคอมพิวเตอร์ คณะวิทยาศาสตร์ สถาบันราชภัฏ สวนดุสิต]
  3. การวิเคราะห์ และออกแบบระบบคอมพิวเตอร์สมัยใหม่ [รัชนี กัลยาวินัย และอัจฉรา ธารอุไรกุล]
  4. การออกแบบ และจัดการฐานข้อมูล [โอภาส เอี่ยมสิริวงศ์]
  5. ระบบฐานข้อมูล (Database systems) [ดร.ดวงแก้ว สวามิภักดิ์]
  6. ประสบการณ์ของ อาจารย์เยาวลักษณ์ งามแสนโรจน์ yaowalak@yonok.ac.th ผู้สอนวิชา MIS และ COBOL programming
  7. ประสบการณ์ของ อาจารย์เกศริน อินเพลา ketsarin@yonok.ac.th ที่ปรึกษาโครงานวิชาสัมมนาคอมพิวเตอร์
  8. ประสบการณ์ของ อาจารย์ถนอม คณิตปัญญาเจริญ thanom@yonok.ac.th ผู้สอนวิชา System analysis and design
  9. ประสบการณ์ของ อาจารย์อมรทิพย์ ประยูรวงค์ rung@yonok.ac.th ผู้สอนวิชา Database management
9. แบบฝึกหัด
  1. ให้เขียน ER model ของ entity ต่อไปนี้ : นักเรียน, อาจารย์ที่ปรึกษา
  2. ให้เขียน ER model ของ entity ต่อไปนี้ : นักเรียน, วิชา
  3. ให้เขียน ER model ของ entity ต่อไปนี้ : ลูกค้า, รถยนต์
  4. ให้เขียน ER model ของ entity ต่อไปนี้ : หมอ, คนไข้
  5. ให้เขียน ER model ของ entity ต่อไปนี้ : ข้อมูลโครงการ, บัญชีโครงการ
  6. ให้เขียน ER model ของ entity ต่อไปนี้ : คนขับ, รถบัส, ผู้โดยสาร
  7. ให้เขียน ER model ของ entity ต่อไปนี้ : ลูกค้า, ขาย, สินค้า
  8. ให้เขียน ER model ของ entity ต่อไปนี้ : ลูกค้า, ชำระหนี้, ใบสั่ง, สินค้า
  9. นำผลการ normalization ไปทำ denormalization อีกครั้ง
ใช้เวลาโหลดเว็บเพจ = 151 มิลลิวินาที ความสูง = 7121 จุด ความกว้าง = 1264 จุด
"ไม่เริ่มต้นในวันนี้ จะไม่มีทางสำเร็จในวันพรุ่ง" โดย โยฮัน ว็อล์ฟกัง ฟ็อน เกอเทอ
หน้าหลัก
Thaiabc.com
Thainame.net
Lampang.net
มหาวิทยาลัยเนชั่น
HTML
PHP
MySQL
JAVA
Teach Pro.
Online quiz
Research
Flowchart
SPSS
Datastructure
KM = Sharing
Batch File
Linux
ปฏิทินวันหยุด
วิทยาการคำนวณ
เกี่ยวกับเรา
FB : Thaiall
Blog : เทคโนโลยี
สนับสนุนเรา
รับความคิดเห็น
Thaiall.com