С чего начинать проектирования базы данных?

Question

[ahmed_al_asad]

Вообщем начну с того, что надо сделать дипломную работу, собрался делать "Система управления школьниками". Хочу делать веб-морду, выбрал яп python и фреймворк django 1.10. В проекте задумано так, любой родитель может зайти на сайте и посмотреть успеваемость, посещаемость и т.д своего ребенка. В каждой школе есть, директор, учителя, ученики, и все они друг с другом связаны. Это легко реализовать если ты делаешь эту систему для одной школы, а если в городе 200 школ? И для каждой школы все отдельно делать? Создавать отдельное приложения с миграция и т.д в django для каждой школы? В голове все продумал, но когда решился проектировать БД, то стало совсем не легко.

PS Я не прошу вас, решать эту задачу за меня. Я хочу, чтобы опытные люди подали совет, с чего лучше начинать? Как поступать правильнее? Как все это реализовать без подводных камней.
PSS Вообщем я учусь на 2 курсе, еще есть 2.5 года до дипломки, можно все хорошо обдумать.

Начал делать ТЗ, чуть-чуть сделал.

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

[RoverWhite]

Делать отдельные решения для каждой школы не надо. Достаточно сделать одно.
Начните с того что подумайте какие функции будет иметь Ваша система, какую информацию и кому она будет предоставлять.
Постарайтесь расписать на бумаге Роли участников системы (директор, родитель, учитель, ученик), какие действия они могут предпринимать на портале, какую информацию им портал предоставляет, какую информацию позволяет вводить.
После этого постарайтесь выделить информационные сущности (пользователь, родитель, учитель, ученик, директор, школа, класс, предмет, урок, расписание уроков, класс, оценка, домашнее задание итд).
Затем перейдите к описанию отдельных элементов этих сущностей (оценка - цифра оценка, ссылка на школа, на класс, на ученик, на предмет, на урок, на дату, на учителя, дата оценки, комментарий учителя итд.)
Подумайте какие типы данных вы будете использовать для хранения информации.
Создайте диаграмму будущей базы данных.
Продумайте как Ваши сущности будут связаны между собой.

Answer 4

[sim3x]

Не используй термины из СУБД - таблица, поля и тд
При работе с джанго, часть функционала субд используеться за сценой и не требует твоего вмешательства
Однако, проектирование моделей требует от тебя использования 3НФ

Итак тебе нужно почитать, как сделать CustomUser в джанго и как ты будешь расширять управление правами доступа для ограничения доступа директор_может_управлять_только_своей_школой и тп

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)
    # ...

В принципе, нет никакой необходимости сразу делать идеальную конструкцию - можно пошагово добавлять акторов и их функционал

Comments

[Павел Аксенов]

Тише, не горячись.) Не нужно кучу таблиц с юзерами делать. Все это можно решить родными группами и родными правами(думаю и кастомного юзера делать не обязательно ). Даже не ожидал от тебя подобного ответа, видимо поспешил).

[sim3x]

hellmin: как сделать все в 3НФ если юзерытак различаются
Как вствоенными средствами ограничить доступ юзера "директор" к записям других школ?
Как можно не делать кастомного пользователя, если у ученика может не быть емаила?