SQL 데이터베이스 모델링: 데이터를 위한 디자인

8878 단어
표지 사진 - Undraw에서 제공하는 데이터

소개


Hi, it me


저의 시리즈 글인 에서 첫 번째 글을 읽으신 것을 환영합니다.이 글은 관계 데이터베이스 환경에서 데이터 디자인을 위한 고급 개술로 관계 데이터베이스는 우리가 데이터베이스를 디자인하는 방식을 바꿀 수 있다.많은 프로그래머들이 습관적으로 대상을 대상으로 하는 디자인 모델과 달리 데이터를 대상으로 하는 디자인 모델은 데이터와 기능을 독립된 실체로 간주하고 대상을 대상으로 하는 디자인 모델은 데이터와 기능을 하나의 대상에 봉인하는 것을 의미할 수 있다.
이런 디자인 방법은 처음에는 게임 개발을 고려한 상황에서 기록되었지만 그 목표와 실현은 SQL의 작업 방식과 밀접한 관계를 가진다.대상을 향한 방법이 더 나쁘거나 유행이 지난 것이 아니라 다른 방법으로 문제를 보는 것이다.

데이터와 대상방향


It's showdown time


우리는 프로젝트 예시를 통해 이 두 방법 간의 약간의 차이를 보여 준다.

스크립트


너는 학교를 위해 새로운 과정 등록 신청을 개발해야 한다.응용 프로그램 사용자는 학생과 교사로 각자의 역할에 따라 자신의 과정을 분배할 수 있다.매 과목마다 교사 한 명과 수량이 제한된 학생 정원만 있을 수 있다.
나는 나머지 세부 사항을 생략할 것이다. 왜냐하면 이것이 바로 우리가 지적해야 할 방법 중의 일부 차이이기 때문이다.

대상방향 방법


대상을 대상으로 하는 방법을 사용하면 교사와 학생의 능력을 봉인하는 전체적인 유형부터 시작할 수 있다.예를 들어 User류는 하위 클래스와 시스템의 상호작용 능력을 나타내고 Course류는 과정 데이터와 방법을 포함한다.다음에 우리는 Teacher 클래스와 Student 클래스를 만들 수 있습니다. 이 클래스는 User 클래스 중의 몇 가지 방법을 계승하고 다시 쓸 수 있습니다.
다음은 코드 형식(C# 구문)의 모양입니다.
public abstract class User {
  private string _name;
  // ...other fields
  public abstract bool IsEnrolledInCourse(string courseName);
  // ...other methods
}

public class Student : User {
  private float _gpa;
  // ...other fields
  public override bool IsEnrolledInCourse(string courseName) { /* some implementation */ }
  // ...other methods
}

public class Teacher : User {
  // ...fields
  public override bool IsEnrolledInCourse(string courseName) { /* some implementation */ }
  // ...other methods
}

public class Course {
  private string _name;
  // ...other fields & methods
}

데이터를 위한 방법


다른 한편, 데이터에 대한 방법은 IsEnrolledInCourse()Teacher 클래스 이외의 Student 함수를 재구성한다.사실상 상술한 모든 클래스에서 변이되거나 상태를 검사하는 함수는 재구성될 것이다. (따라서 IsEnrolledInCourse() 논리가 Course 클래스에 있는지 여부는 중요하지 않다.이제 재구성된 코드가 어떻게 보이는지 살펴보고, 왜 우리가 이렇게 선택했는지 설명하겠습니다.
public static class Students {
  public static List<string> Name;
  public static List<float> Gpa;
  // ...other fields
}

public static class Teachers {
  public static List<string> Name;
  // ...other fields
}

public static class Courses {
  public static List<string> Name;
  // ...other fields
}

public static class EnrolledStudents {
  public static List<string> courseName;
  public static List<string> studentName;
}

public static class EnrolledTeachers {
  public static List<string> courseName;
  public static List<string> teacherName;
}
주요 차이점:
  • 각 클래스는 대상이 아니라 특정 실체
  • 의 모든 데이터에 대한 인용
  • 유효한 데이터만 삽입하거나 삭제해야 하기 때문에 빈 값이 없어야 합니다
  • 데이터 유형 유지 관리 불필요
  • Ex) 학생이 최소한 하나의 클래스를 등록했는지 확인하려면 학생의 이름이 등록된 학생 목록에 있는지 확인할 수 있습니다. 학생의 대상
  • 에서 유지보수bool _isEnrolled 변수가 아닌
  • 다태성은 서로 다른 실체(교사와 학생을 자신의 대상으로 분할)를 가지고 서로 다른 함수를 응용하여 처리한다
  • SQL을 사용하지 않았다면, 이것은 SQL이 데이터 기록(표)을 구성하는 방식과 유사합니다!

    생각을 끝내다


    프로그래밍을 어떻게 하는지 새로운 시각을 제공하고 대상을 대상으로 하는 디자인 모델이 매번 완벽한 해결 방안이 아니기를 바랍니다.함수식 프로그래밍을 좋아하는 사람들에게는 너무 익숙한 것 같다. 기능과 데이터를 분리하는 것이 중점이기 때문이다. 그러나 이것은 어떻게 데이터를 조직하고 방문해야 하는지를 상세하게 설명한다.
    이것은 관계 데이터베이스에 대한 소개를 끝내고 다음 글에서 실체 관계 모델을 어떻게 사용하여 데이터에 대한 디자인을 직관적으로 묘사하는지 토론할 것이다.
    만약 이 점을 해냈다면 댓글에서 데이터에 대한 디자인과 SQL에 대한 느낌을 알려주십시오.당신은 초보자입니다. 데이터베이스에 들어가기를 원합니까?아니면 데이터베이스를 대규모로 배치했는데 내가 완전히 틀렸다고 생각하십니까?알려줘!

    학점과 진일보한 읽기


    Original Article on Data-Oriented Design by Noel Llopis
    Book on Data-Oriented Design by Richard Fabian
    Data-Oriented Design in Practice: Unity DOTS

    I was inspired to write this after reading post on object relational mapping (ORM) libraries, check it out!


    좋은 웹페이지 즐겨찾기