How to start database design?

Question

PostgreSQL

In general, I'll start with the fact that I need to do a thesis, I was going to do the "School Management System". I want to make a web face, I chose python and the django 1.10 framework. The project is conceived in such a way that any parent can go to the site and see the progress, attendance, etc. of their child. Every school has a director, teachers, students, and they are all connected with each other. It is easy to implement if you are making this system for one school, but what if there are 200 schools in the city? And for each school to do everything separately? Create a separate application with migrations etc in django for each school? I thought of everything in my head, but when I decided to design a database, it became not at all easy.
PS I'm not asking you to solve this problem for me. I want experienced people to give advice, where is the best place to start? How to do it right? How to implement all this without pitfalls.
PSS In general, I'm a 2nd year student, there are still 2.5 years before my diploma, you can think about everything well.
I started making TK , did a little.

Answer 1

Начните с изучения нормальных форм данных.
вики

Answer 2

собрался делать "Система управления школьниками"

- всегда о такой мечтал!
Простите, не сдержался, далее по делу:
Я не могу знать Ваши личные предпочтения и манеры преподавания к которой Вы привыкли или считаете наиболее верными или предпочтительными, но в своей преподавательской практике, я не редко использовал метод "визуализации" происходящего. Довольно сложно объяснить человеку, который не работал с сетями, что такое IP4-пакет... но, когда рисуешь это визуально, качество восприятия значительно улучшается.
Собственно, к чему я это... Возьмите лист бумаги, или холст (paint, photoshop, etc.), или программу для рисования блок-схем, или программу для создания скетчей или что-то подобное и попробуйте отрисовать все таблицы/объекты БД и связи между ними. Так же, аналогичный функционал есть во многих программа для работы с БД (визуализация таблиц и их связей). Когда Вы будете визуально видеть и представлять объекты - гораздо проще воспринимать происходящее.
Пример из жизни - попробуйте объяснить человеку, что такое таблица реляционной БД... а если провести аналогию с листом из Excel - в 95% случаев, понимание приходит практически моментально.
Так же могу сказать, что выбор на начальном этапе PostgreSQL - не лучшая идея. PostgreSQL - очень классная БД, если Вы действительно понимаете зачем она Вам нужна и почему именно она. То есть, в тех случаях, когда Вам уже жмут "MySQL-штаны" и не хватает простора для действий и нескольких сотен лишних параметров, которые нужно подкрутить и поднастроить, а так же феерического количества параметров и возможностей самой БД - PostgreSQL будет оптимальным выбором, в ином же случае, Вы будете проклинать мир, разработчиков и всё сущее, постоянно сталкиваясь с некоторыми трудностями, которые иногда могут даже показаться глупостями (хотя, в 99% случаев это не так). Например, чего только стоит момент, что в PostgreSQL нет "табличных движков", или нельзя поменять местами ранее созданные колонки в таблице без полной перезаписи всей таблицы, или дюжина индексов (и какой выбрать?!), против куда более скудного количества в MySQL...
Мои студенты довольно часто сталкивались с подобными проблемами, по этому, мы пришли к такой практике - база проектируется и прототипируется на MySQL, меняется там до посинения, пока не будет выверен действительно нужный вектор развития БД, код обкатывается... а потом, проект легко и непринуждённо переезжает на PG, где впоследствии снабжается некоторыми плюшками и полезностями уровня PG (теми, который в MySQL-е нет).
Я рекомендую Вам, так же как и моим студентам - сначала спроектировать базу в MySQL, мы обычно делаем это в программе HeidiSQL (бесплатная), всё очень наглядно и разноцветно. Обкатать Ваш код и логику работы БД, а потом уже, если сильно не терпится - переносить на Postgres.
Из личного опыта, могу сказать, что многие выбирают PostgreSQL, т.к. он(а) "круче". Это не совсем так, или, совсем не так... Из множества проектов, на PG мы поставили только один, там база данных исчислялась многими десятками и сотнями гигабайт, количество таблиц приближалось к тысяче, а кол-во записей в отдельно взятых таблицах - десятками миллионов. Но, даже сейчас я работаю в поддержке проекта, объёмы данных которого переваливают за 1Тб, и всё прекрасно живёт на MySQL. По этому, если Вы выбрали PG исключительно по каким-то идеологическим, а не техническим соображениям - подумайте ещё раз.

Answer 3

There is no need to make separate decisions for each school. It is enough to do one.
Start by thinking about what features your system will have, what information and to whom it will provide.
Try to write down on paper the roles of the system participants (principal, parent, teacher, student), what actions they can take on the portal, what information the portal provides them with, what information they can enter.
After that, try to identify information entities (user, parent, teacher, student, director, school, class, subject, lesson, lesson schedule, grade, grade, homework, etc.).
Then proceed to the description of the individual elements of these entities (grade - grade number, link to school, class, student, subject, lesson, date, teacher, grade date, teacher comment, etc.)
Think about what types of data you will use to store information.
Create a diagram of the future database.
Think about how your entities will be related to each other.

Answer 4

Don't use DBMS terms - table, fields, etc.
When working with django, part of the subd functionality is used behind the scenes and doesn't require your intervention
However, model design requires you to use 3NF
So you need to read how to make a CustomUser in django and how you will expand access rights management to restrict access principal_can_manage_only_his_school, etc.

spoiler

class School(models.Model):
    name = models.CharField(max_length=200)
    address = models.CharField(max_length=200)


class MyUser(AbstractBaseUser):
    GROUP_DIRECT = 0
    GROUP_TEACHER = 1
    # ...
    GROUP_PARENT = 8
    GROUP_STUDENT = 9
    GROUP = (
        (GROUP_DIRECT, 'Director'),
        (GROUP_TEACHER, 'Teacher'),
        # ...
        (GROUP_PARENT, 'Parent'),
        (GROUP_STUDENT, 'Student'),
    )

    name = models.CharField(max_length=200)
    email = models.EmailField()
    group = models.IntegerField(choices=GROUP)


class Lesson(models.Model):
    name = models.CharField(max_length=200)
    # ...
    school = models.ForeignKey(School)
    

class Director(MyUser):
    description = models.CharField(max_length=200)
    # ...
    school = models.ForeignKey(School)
    

class Teacher(MyUser):
    description = models.CharField(max_length=200)
    # ...
    school = models.ForeignKey(School)


class Student(MyUser):
    description = models.CharField(max_length=200)
    # ...
    school = models.ForeignKey(School)


class Parent(MyUser):
    description = models.CharField(max_length=200)
    children = models.ManyToManyField(Student)
    # ...

In principle, there is no need to immediately make an ideal design - you can add actors and their functionality step by step