Thiết kế Cơ sở dữ liệu Giúp Tổ chức Giáo viên, Bài học và Học sinh như thế nào?

Đầu tư vào kiến ​​thức mang lại lợi ích tốt nhất.

Benjamin Franklin

Trong thế giới hiện đại, giáo dục có mặt khắp nơi. Bây giờ hơn bao giờ hết, nó đóng một vai trò quan trọng trong xã hội của chúng ta. Trên thực tế, điều quan trọng là nhiều người trong chúng ta tiếp tục con đường học vấn tốt sau khi học xong đại học hoặc cao đẳng.

Tất cả chúng ta đều đã nghe nói về học tập suốt đời, giáo dục không chính quy và các hội thảo dành cho mọi lứa tuổi. Những phương pháp này khác với giáo dục chính quy về nhiều mặt, nhưng chúng cũng có những điểm chung. Có các lớp học, bài học, giáo viên và học sinh. Và cũng giống như trong cài đặt truyền thống, chúng tôi sẽ muốn theo dõi lịch học, dữ liệu tham dự và thành tích của giáo viên hoặc học sinh. Làm thế nào chúng ta có thể thiết kế một cơ sở dữ liệu để đáp ứng những nhu cầu này? Đó là những gì chúng tôi sẽ đề cập trong bài viết này.

Giới thiệu Mô hình Cơ sở dữ liệu Giáo dục của Chúng tôi

Mô hình được trình bày trong bài viết này cho phép chúng tôi lưu trữ dữ liệu về:

• lớp học / bài giảng
• người hướng dẫn / giảng viên
• sinh viên
• tham dự bài giảng
• thành tích của sinh viên / giảng viên

Chúng tôi cũng có thể sử dụng mô hình này làm thời khóa biểu ở trường, cho các hoạt động nhóm khác (học bơi, hội thảo khiêu vũ) hoặc thậm chí cho các hoạt động một kèm một như dạy kèm. Vẫn còn rất nhiều không gian để cải tiến, chẳng hạn như lưu trữ dữ liệu vị trí lớp học hoặc thời lượng hội thảo; chúng tôi sẽ đề cập đến những vấn đề này trong các bài viết sắp tới.

Hãy bắt đầu với các phần tử cơ sở dữ liệu Giáo dục cơ bản của chúng tôi:các bảng.

Bộ ba lớn:Bàn học sinh, giáo viên hướng dẫn và lớp học

student , instructor và class bảng tạo nên cốt lõi của cơ sở dữ liệu của chúng tôi.

student bảng, được hiển thị ở trên, được sử dụng để lưu trữ dữ liệu cơ bản về học sinh, nhưng nó có thể được mở rộng tùy theo nhu cầu cụ thể. Ngoại trừ ba thuộc tính liên hệ, tất cả các thuộc tính trong bảng là bắt buộc:

• first_name - tên của học sinh
• last_name - họ của học sinh
• birth_date - ngày sinh của học sinh
• contact_phone - số điện thoại của sinh viên
• contact_mobile - số điện thoại di động của sinh viên
• contact_mail - địa chỉ email của sinh viên
• category_id - là tham chiếu đến category mục lục. Với cấu trúc này, chúng tôi chỉ giới hạn một danh mục cho mỗi học sinh. Điều đó hoạt động trong hầu hết các trường hợp, nhưng trong một số trường hợp, chúng tôi có thể cần chỗ để liệt kê nhiều danh mục. Như bạn có thể thấy, thêm mối quan hệ nhiều-nhiều kết nối student bảng với category từ điển giải quyết vấn đề này. Tuy nhiên, trong trường hợp này, chúng tôi sẽ cần viết các truy vấn phức tạp hơn để xử lý dữ liệu của mình.

Vì chúng tôi đã đề cập đến vấn đề này, chúng ta hãy tiếp tục và thảo luận về category bảng ở đây.

Bảng này là một từ điển được sử dụng để phân nhóm học sinh dựa trên các tiêu chí nhất định. name thuộc tính là dữ liệu duy nhất trong bảng (bên cạnh id , khóa chính) và nó là bắt buộc. Một bộ giá trị có thể được lưu trữ ở đây là tình trạng việc làm của sinh viên:“sinh viên”, “có việc làm”, “thất nghiệp” và “đã nghỉ hưu”. Chúng tôi cũng có thể sử dụng các nhóm khác dựa trên một số tiêu chí cụ thể, chẳng hạn như “thích yoga”, “thích đi bộ đường dài”, “thích đạp xe” và “không thích bất cứ thứ gì”.

instructor bảng chứa danh sách tất cả các giảng viên / giảng viên trong tổ chức. Các thuộc tính trong bảng là:

• first_name - tên của người hướng dẫn
• last_name - họ của người hướng dẫn
• title - chức danh của người hướng dẫn (nếu có)
• birth_date - ngày sinh của người hướng dẫn
• contact_phone - số điện thoại của người hướng dẫn
• contact_mobile - số điện thoại di động của người hướng dẫn
• contact_mail - địa chỉ email của người hướng dẫn

title và cả ba contact thuộc tính không bắt buộc.

student bảng và instructor bảng chia sẻ cấu trúc tương tự, nhưng có một khả năng khác để tổ chức thông tin này. Cách tiếp cận thứ hai là có một person bảng (lưu trữ tất cả dữ liệu nhân viên và sinh viên) và có mối quan hệ nhiều-nhiều cho chúng ta biết tất cả các vai trò được giao cho người đó. Ưu điểm quan trọng nhất của cách tiếp cận thứ hai là chúng tôi sẽ chỉ lưu trữ dữ liệu một lần. Nếu ai đó là người hướng dẫn trong một lớp học và một sinh viên trong một lớp học khác, họ sẽ chỉ xuất hiện một lần trong cơ sở dữ liệu nhưng với cả hai vai trò được xác định.

Tại sao chúng tôi chọn cách tiếp cận hai bảng cho mô hình cơ sở dữ liệu giáo dục của mình? Nói chung, sinh viên và người hướng dẫn cư xử khác nhau, cả trong cuộc sống thực và trong cơ sở dữ liệu của chúng tôi. Do đó, có thể là khôn ngoan khi lưu trữ dữ liệu của họ một cách riêng biệt. Chúng tôi có thể tìm các cách khác để hợp nhất bất kỳ thông tin nào của cùng một người xuất hiện trong cả hai bảng (ví dụ:cặp truy vấn chèn / cập nhật dựa trên id bên ngoài, chẳng hạn như số an sinh xã hội hoặc số VAT).

class bảng là một danh mục chứa thông tin chi tiết về tất cả các lớp. Chúng ta có thể có nhiều trường hợp của mỗi loại lớp. Các thuộc tính trong bảng như sau (tất cả đều là bắt buộc ngoại trừ end_date ):

• class_type_id - là tham chiếu đến class_type từ điển.
• name - là tên viết tắt của lớp học.
• description - mô tả này cụ thể hơn mô tả trong class_type bảng.
• start_date - ngày bắt đầu của lớp học.
• end_date - ngày kết thúc lớp học. Điều này không bắt buộc vì không phải lúc nào chúng tôi cũng có thể biết trước ngày kết thúc chính xác cho mỗi lớp học.
• completed - là một giá trị Boolean biểu thị liệu tất cả các hoạt động trong lớp đã lên kế hoạch đã kết thúc hay chưa. Điều này rất hữu ích khi chúng ta đã đạt đến end_time theo kế hoạch cho một lớp học nhưng các hoạt động khác của lớp vẫn chưa được hoàn thành.

class_type table là một danh mục đơn giản, nhằm mục đích lưu trữ thông tin cơ bản về các bài giảng hoặc lớp học được cung cấp cho sinh viên. Nó có thể chứa các giá trị như “Tiếng Anh (nhóm)”, “Tiếng Ba Lan (nhóm)”, “Tiếng Croatia (nhóm)”, “Tiếng Anh (trực tiếp)” hoặc “Bài học khiêu vũ”. Nó chỉ có hai thuộc tính bắt buộc - name và description , cả hai đều không cần giải thích thêm.

class_schedule bảng chứa thời gian cụ thể cho các bài giảng và lớp học. Tất cả các thuộc tính trong bảng là bắt buộc. class_id thuộc tính là một tham chiếu đến class bảng, trong khi start_time và end_time là thời gian bắt đầu và kết thúc của bài giảng cụ thể đó.

Ai ở đây? Các bảng liên quan đến điểm danh

attend bảng lưu trữ thông tin về học sinh đã tham dự lớp học nào và kết quả cuối cùng. Các thuộc tính trong bảng là:

• student_id - là một tham chiếu đến student bảng
• class_id - là một tham chiếu đến class bảng
• class_enrollment_date - là ngày sinh viên bắt đầu tham gia lớp học đó
• class_drop_date - ngày sinh viên bỏ lớp. Thuộc tính này chỉ có giá trị nếu học sinh bỏ lớp trước ngày kết thúc lớp học. Trong trường hợp đó, drop_class_reason_id giá trị thuộc tính cũng phải được đặt.
• drop_class_reason_id - là tham chiếu đến drop_class_reason bảng
• attendance_outcome_id - là tham chiếu đến attendance_outcome bảng

Tất cả dữ liệu ngoại trừ class_drop_date và drop_class_reason_id bắt buộc. Hai mục này sẽ được điền nếu và chỉ khi một học sinh bỏ lớp.

drop_attendance_reason table là một từ điển chứa nhiều lý do khác nhau khiến học sinh có thể bỏ khóa học. Nó chỉ có một thuộc tính, reason_text , và nó là bắt buộc. Một tập hợp giá trị mẫu có thể bao gồm:“bệnh tật”, “mất hứng thú”, “không có đủ thời gian” và “lý do khác”.

attendance_outcome bảng chứa các mô tả về hoạt động của sinh viên trong một khóa học nhất định. outcome_text là thuộc tính duy nhất trong bảng và là thuộc tính bắt buộc. Tập hợp các giá trị có thể có là:“đang thực hiện”, “đã hoàn thành thành công”, “đã hoàn thành một phần” và “chưa hoàn thành lớp”.

Ai chịu trách nhiệm? Các bảng liên quan đến giảng dạy

teach , drop_teach_reason và teach_outcome các bảng sử dụng logic tương tự như attend , drop_attendance_reason và attendance_outcome những cái bàn. Tất cả các bảng này lưu trữ dữ liệu về các hoạt động liên quan đến khóa học của người hướng dẫn.

teach bảng được sử dụng để lưu trữ thông tin về giảng viên đang giảng dạy lớp nào. Các thuộc tính trong bảng là:

• instructor_id - là tham chiếu đến instructor bảng.
• class_id - là một tham chiếu đến class bảng.
• start_date - là ngày người hướng dẫn bắt đầu làm việc cho lớp học đó.
• end_date - là ngày mà người hướng dẫn ngừng làm việc trên lớp học đó. Điều này không bắt buộc vì chúng tôi không thể biết trước liệu người hướng dẫn có giảng dạy vào ngày kết thúc lớp học hay không.
• drop_teach_reason_id - là tham chiếu đến drop_teach_reason bàn. Không bắt buộc vì người hướng dẫn có thể không bỏ lớp.
• teach_outcome_id - là tham chiếu đến teach_outcome_reason bảng.

drop_teach_reason bảng là một từ điển đơn giản. Nó bao gồm một tập hợp các giải thích có thể xảy ra tại sao giảng viên đã hoàn thành lớp học trước ngày kết thúc. Chỉ có một thuộc tính bắt buộc:reason_text . Đây có thể là “bệnh tật”, “chuyển sang dự án / công việc khác”, “nghỉ việc” hoặc “lý do khác”.

teach_outcome bảng mô tả thành công của người hướng dẫn trong một khóa học cụ thể. outcome_text là thuộc tính duy nhất của bảng và là thuộc tính bắt buộc. Các giá trị có thể có cho bảng này có thể là:“đang thực hiện”, “hoàn thành thành công”, “hoàn thành một phần” và “chưa hoàn thành lớp giảng dạy”.

student_presence bảng được sử dụng để lưu trữ dữ liệu về sự hiện diện của sinh viên cho một bài giảng cụ thể. Chúng ta có thể giả định rằng đối với mỗi bài giảng, giảng viên sẽ ghi nhận sự hiện diện và / hoặc vắng mặt của tất cả sinh viên. Các thuộc tính trong bảng là:

• student_id - là một tham chiếu đến student bảng
• class_schedule_id - là tham chiếu đến class_schedule bảng
• present - là một Boolean đánh dấu liệu sinh viên có hiện diện trên bài giảng hay không

Chúng tôi có thể theo dõi sự hiện diện của sinh viên trên một lớp cụ thể bằng một truy vấn như truy vấn sau đó (giả sử rằng @id_class chứa id lớp mà chúng tôi muốn).

 SELECT a.id, CONCAT (a.first_name, '', a.last_name) AS student_name, a.number_total, CONCAT (CONVERT (a.number_present / a.number_total * 100, DECIMAL (5,2)), '%') AS phần trăm, a.attendance_outcomeFROM (SELECT student.id, student.first_name, student.last_name, SUM (CASE WHEN student_presence.present =True THEN 1 ELSE 0 END) AS number_present, COUNT (DISTINCT class_schedule.id) AS number_total, Bing_outcome.outcome_text AS Lớp học INNER Tham gia Lớp học INNER Tham gia BẬT class.id =tham dự BẬT lớp học.id =Tham dự.class_id Học sinh INNER THAM GIA BẬT tham dự.student_id =student.id LEFT THAM GIA class_schedule ON class_schedule.class_id =class.id LEFT THAM GIA student_presence ON student_pidence.st .id AND student_presence.class_schedule_id =class_schedule.id LEFT THAM GIA HÃY LỚN TRÁI BẤT CỨ THAM GIA KÍCH THƯỞNG_outcome BẬT BẬT KỲ_outcome.id =tham dự.attendance_outcome_idWHERE class.id =@id_classGROUP BY student.id, student.first_name, student.last_name, Honor_outcome.outcome_text 
  
 

 Bảng “coach_presence” sử dụng logic tương tự như bảng “student_presence”, nhưng ở đây chúng tôi muốn tập trung vào các giảng viên. Các thuộc tính trong bảng là:
 
 
 instructor_id - là tham chiếu đến instructor bảng 
 
 class_schedule_id - là tham chiếu đến class_schedule bảng 
 
 present - là giá trị Boolean đại diện cho việc người hướng dẫn có trình bày trong bài giảng hay không 
 
 

 Chúng tôi có thể sử dụng truy vấn bên dưới để theo dõi hoạt động của người hướng dẫn trong lớp:
 
 SELECT a.id, CONCAT (a.first_name, '', a.last_name) AS teacher_name, a.number_total, CONCAT (CONVERT (a.number_present / a.number_total * 100, DECIMAL (5,2)), '%') Tỷ lệ phần trăm AS, a.teach_outcomeFROM (CHỌN NGƯỜI hướng dẫn.id, Người hướng dẫn.first_name, Người hướng dẫn.last_name, SUM (TRƯỜNG HỢP KHI Người hướng dẫn_presence.present =True THEN 1 ELSE 0 KẾT THÚC) AS number_present, COUNT (DISTINCT class_schedule.id) AS number_total, dạy_outcome.outcome_text AS lớp dạy_outcomeFROM INNER JOIN dạy ON class.id =dạy.class_id INNER JOIN giảng viên TRÊN DH.instructor_id =direct .id AND direct_presence.class_schedule_id =class_schedule.id LEFT THAM GIA DH_outcome TRÊN DH_outcome.id =dạy.teach_outcome_idWHERE class.id =@id_classGROUP BY teacher.id, teacher.first_name, teacher.last_name, teacher_outcome.outcome_text) a  Bây giờ, chúng ta hãy kết thúc bằng cách thảo luận về các bảng Người liên hệ. 
 
 Chúng ta có thể gọi cho ai? Bảng người liên hệ 
 

 Trong hầu hết các trường hợp, chúng tôi không cần lưu trữ thông tin liên hệ khẩn cấp (tức là trong trường hợp khẩn cấp, hãy liên hệ với người này). Tuy nhiên, điều này sẽ thay đổi khi chúng ta dạy trẻ em. Theo luật hoặc theo thông lệ, chúng tôi cần có Người liên hệ cho từng đứa trẻ mà chúng tôi đang dạy. Trong các bảng mô hình của chúng tôi - contact_person , contact_person_type và contact_person_student - chúng tôi chứng minh điều này có thể được thực hiện như thế nào. 
 
  
 

 contact_person bảng là danh sách những người có liên quan đến học sinh. Tất nhiên, chúng ta không cần liệt kê tất cả họ hàng; hầu hết chúng tôi sẽ có một hoặc hai địa chỉ liên hệ cho mỗi học sinh. Đây là một cách tốt để tìm “người bạn sẽ gọi” khi học sinh cần hoặc muốn về sớm. Các thuộc tính trong bảng là:
 
 
 first_name - là tên của người liên hệ 
 
 last_name - là họ của người đó 
 
 contact_phone - là số điện thoại của người đó 
 
 contact_mobile - là số điện thoại di động của người đó 
 
 contact_mail - là địa chỉ email của người đó 
 
 

 Chi tiết liên hệ là không bắt buộc, mặc dù chúng rất hữu ích. 
 
  
 

 contact_person_type bảng là một từ điển với một thuộc tính bắt buộc, duy nhất:type_name . Ví dụ về các giá trị được lưu trữ trong bảng này là:“mẹ”, “bố”, “anh trai”, “chị gái” hoặc “chú”. 
 
  
 

 contact_person_student bảng là một quan hệ nhiều-nhiều kết nối Người liên hệ và kiểu của họ với học sinh. Các thuộc tính trong bảng là (tất cả đều là bắt buộc):
 
 
 contact_person_id - là tham chiếu đến contact_person bảng 
 
 student_id - là một tham chiếu đến student bảng 
 
 contact_person_type_id - là tham chiếu đến contact_person_type bảng 
 
 

 Có thể đáng nói rằng mối quan hệ nhiều-nhiều này kết nối ba bảng với nhau. Cặp thuộc tính contact_person_id và student_id được sử dụng làm khóa thay thế (DUY NHẤT). Bằng cách đó, chúng tôi sẽ tắt các mục nhập trùng lặp kết nối từng học sinh với cùng một người liên hệ. Thuộc tính contact_person_type_id không phải là một phần của khóa thay thế. Nếu vậy, chúng ta có thể có nhiều mối quan hệ cho cùng một người liên hệ và cùng một học sinh (sử dụng các kiểu quan hệ khác nhau) và điều đó không có ý nghĩa gì trong các tình huống thực tế. 
 

 Mô hình được trình bày trong bài viết này có thể đáp ứng hầu hết các nhu cầu thông thường. Tuy nhiên, các phần của mô hình có thể bị loại trừ trong một số trường hợp, ví dụ:chúng tôi có thể sẽ không cần toàn bộ phân khúc người liên hệ nếu học viên của chúng tôi là người lớn. Như tôi đã nói trước đây, chúng tôi sẽ kịp thời bổ sung các cải tiến cho vấn đề này. Vui lòng thêm các đề xuất và chia sẻ kinh nghiệm của bạn trong các phần thảo luận.