Проектирование базы данных для школы


Эта система должна управлять студентов, преподавателей, сотрудников и аттестации. Это для производства, а не школьное задание. Таким образом, Пожалуйста, дайте мне знать, если я могу улучшить по какому-либо аспекту. :)

Моя главная забота-это автоматизация. Я бы хотел, чтобы мое приложение могло работать независимо от того, если я все еще существуют.

Я с помощью SQLite в качестве базы данных:

create table User
(
ID integer primary key autoincrement,
Username string,
Password string
);

create table Area
(
ID integer primary key autoincrement,
Name string
);

create table Subject
(
ID integer primary key autoincrement,
Name string,
Abbreviation string,
IDArea integer references Area(ID)
);

create table Level
(
ID integer primary key autoincrement,
Name string,
Principle string
);

create table Grade
(
ID integer primary key autoincrement,
Name string,
IDLevel integer references Level(ID),
Observation string
);

create table StaffType
(
ID integer primary key autoincrement,
Name string
);

create table Staff
(
ID integer primary key autoincrement,
IDStaffType integer references StaffType(ID),
Name string,
LastNameFather string,
LastNameMother string,
DateOfBirth string,
PlaceOfBirth string,
Sex string,
Carnet string,
Telephone string,
MobilePhone string,
Address string,
FatherName string,
MotherName string,
FatherContact string,
MotherContact string,
FatherPlaceOfWork string,
MotherPlaceOfWork string,
DateOfHiring string,
YearsOfService string,
Formation string,
Specialty string,
Category string,
Salary string
);

create table GradeParalelo
(
ID integer primary key autoincrement,
IDGrade integer references Grade(ID),
IDStaff integer references Staff(ID),
Name string
);

create table Student
(
ID integer primary key autoincrement,
IDGradeParalelo integer references GradeParalelo(ID),
Rude string,
Name string,
LastNameFather string,
LastNameMother string,
DateOfBirth string,
PlaceOfBirth string,
Sex string,
Carnet string,
Telephone string,
MobilePhone string,
Address string,
FatherName string,
MotherName string,
FatherMobilePhone string,
MotherMobilePhone string,
FatherProfession string,
MotherProfession string,
FatherPlaceOfWork string,
MotherPlaceOfWork string,
Observations string
);

create table Attendance
(
ID integer primary key autoincrement,
IDStudent integer references Student(ID),
Attended string,
Date string
);

create table SubjectGrade
(
ID integer primary key autoincrement,
IDGrade integer references Grade(ID),
IDSubject integer references Subject(ID)
);

create table ScoreRecord
(
ID integer primary key autoincrement,
IDSubject integer references Subject(ID),
IDStudent integer references Student(ID),
FirstTrimester integer,
SecondTrimester integer,
ThirdTrimester integer,
FinalGrade integer,
Year string
);

Entity/Relationship diagram

Любой яркий номер для улучшения?



45058
33
задан 29 января 2011 в 04:01 Источник Поделиться
Комментарии
6 ответов

Одна вещь, которая сразу же выскочила ко мне:

LastNameFather string,
LastNameMother string,
FatherName string,
MotherName string,
FatherContact string,
MotherContact string,
FatherPlaceOfWork string,
MotherPlaceOfWork string,

Ваш дизайн предполагает, что каждый студент будет иметь ровно 1 мать и 1 отец точно. Сейчас я могу сказать, что не будет. Студенты с разведенными родителями может иметь двух матерей и двух отцов, каждый из которых хочет иметь свою контактную информацию, перечисленных. Некоторые студенты, возможно, геем или лесбиянкой родителей, и таким образом двух отцов или двух матерей. Некоторые студенты могут иметь ни, а вместо этого может иметь законного опекуна, ни их отца, ни матери.

Одним из решений этой проблемы было бы иметь таблицу для "человека", а тяга людей к каждому студенту. Определить, является ли это лицо отца или матери (или родителей опекуна). Это также упростит наличие братьев и сестер: вы можете иметь ту же мать, отец и т. д. для нескольких студентов.

Для большинства студентов, это не будет проблемой, но больше, чем вы думаете, так и будет. У этих семей и управления одолжение, что позволяет легко обрабатывать различные семейные сценарии!

24
ответ дан 30 января 2011 в 09:01 Источник Поделиться

Некоторые вещи, которые выскочили

взять Мартин-Йорк предложение и быть последовательными, насколько это возможно, пользователь определении первичного ключа имена, как функция user_id в отличие от код для каждой таблицы, как это сделает его менее запутанным для тех, кто пишет/сохранение в SQL. Для внешних ключей, я бы предложил таблицу сначала например, area_id в отличие от IdArea , как она течет лучше с естественного языка.


  • Глядя на вашу ЭРД, есть места, где он не в состоянии добраться до 3НФ (которая является уровень нормализации базы данных вы должны стремиться к тому, когда это возможно)

  • Используйте правильные типы полей, похоже, что вы используете много строк, таких вещей, как даты аренды должен быть столбец типа timestamp/DateTime и пол может быть перечисление и т. д.

  • Вся контактная/информация Телефон сотрудников и студентов таблицы можно размещать в более подходящих телефона/контакт столами, как один ко многим отношений.

  • Таблицы посещаемости...похоже, что он либо утверждает, что студент посещал школу в определенный день или нет...похоже, это будет что-то больше на каждом уровне класса, как студент смог приехать на полдня и все такое.

  • Может ли сотрудник иметь более чем одного сотрудника тип, если это так, вы должны иметь ассоциативную таблицу, чтобы связать персонала для персонала видах

  • Вместо года службы в штаб, не могли бы вы не просто использовать дату из столбца прокат, чтобы понять это, а не каждый год обновление года столбце служба.

Те вещи, которые я заметил, надеюсь, что это помогает.

11
ответ дан 29 января 2011 в 06:01 Источник Поделиться

Комментарии


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

  2. Чтобы облегчить идентификаторы для чтения либо использовать регистр или отдельные слова с _
    Идентификаторы, как IDArea сбегаются многовато. Так IdArea или ID_Area или Id_Area (помните выбрать стиль и будьте последовательны хотя).

  3. Таблица сотрудники имеет много информации в нем много, который может быть null.
    Я хотел бы иметь таблицу человеку, чтобы держать людей информацию. Затем в таблице отношений, чтобы держать корабли отношениях между людьми. Таким образом, когда ваша БД расширяется (и в бизнес-среде это будет происходить) вы можете выражать другие отношения между сотрудниками.

  4. Связанные с персоналом. Как персонал, я хотел бы сохранить личные данные студента в таблице person. Примечание. Я бы все-таки сохранить в отдельной таблице (или представлении) для сотрудников/студент, у которого есть ссылка в таблице person.

10
ответ дан 29 января 2011 в 05:01 Источник Поделиться

Я согласны с все выше замечания другого, но я остановлюсь на нескольких конкретных моментах:


  1. Вы могли определенно сделать некоторые дополнительные нормализации. Есть места, где это может прийти к решению сознательный не в полной мере нормализовать (там может быть несколько причин этого не делать . . . В зависимости от ваших проблем), но в целом, когда я начинаю видеть те же имена полей, появляющихся в нескольких таблицах (кроме ПК/ФК отношения), я становлюсь подозрительным. Пример (который Мартин Йорк затрагивает, но я возьму на шаг дальше) - это все "люди". Обратите внимание на уровень dupplication между "сотрудники" и таблица "студент" таблицы в отношении матерей/отцов/Worplaces/профессий. Матери и отцы-это люди. Сотрудники тоже люди. Студенты-это люди.

  2. Я заметил, что у вас есть "замечания" в свой студенческий стол. Я настоятельно рекомендую вам определить "наблюдения" таблицы с внешним ключом для "студентов" таблица со следующими полями (в Staff_ID, чтобы записать, кто сделал замечание). С течением времени, наблюдения будут накапливаться, и это будет полезно знать, когда и кто их сделал:

Таблица Наблюдений: Observation_ID, Student_ID, Observation_Date, Наблюдательность, Staff_ID


  1. Я согласна с тем, что там должен быть отдельный "файл contact_info" стол. Далее, я уверен, вы хотите, чтобы отправить ученика (или родителей) почта от времени до времени. Я бы включил в "адреса" стол для этой цели. Я не буду притворяться, что знаю, как это работает в Боливии, но в Штатах, в школах, как отправить по почте табели успеваемости (хотя, родители также могут отслеживать больше прогесс своих студентов через интернет . . .).

  2. Зарплаты сотрудников могут меняться. В то время как вы можете решить, что это приемлемо, чтобы изменить это значение, это еще одна область, где правильных нормализации указывает на персонал-заработная плата таблица, которая содержит идентификатор, зарплата и Effective_Date.

Как далеко вы взять процесс нормализации может быть сложно, но как один или более других наблюдается комментаторы, вы всегда должны стрелять в 3НФ. Я обещаю вам, исходя из собственного печального опыта, что, когда ваш босс решит, что ему нужен отчет, показывающий зарплата сотрудников увеличивается за пятилетний период, вы будете радоваться, что сделали.

Хотя зачастую есть сознательный, дизайн-решение, основанное на "денормализация" на стол, решение должно документироваться для тех, кто, возможно, потребуется, чтобы сохранить свои базы в будущем, когда вы больше не существует.

Надеюсь, что помогает!

4
ответ дан 30 января 2011 в 09:01 Источник Поделиться

Я понимаю, что все выбранные вами имена таблиц и полей понятны и очевидны. Только "GradeParalelo" не имеет смысла для меня.

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

2
ответ дан 29 января 2011 в 05:01 Источник Поделиться

Там, кажется, дублирования, я просто собираюсь поставить изменения для каждой таблицы в отдельный ответ.

Стол Персонала


  1. Мать и отец контактную информацию можно поместить в отдельную таблицу. Таким образом, вы не ограничены, если у кого-то другие контакты

    contact_id, contact_name, relationship, contact_number, contact_address, fk=staff_id

  2. Может ли персонал иметь более одного StaffType? Как может учитель быть тренером? Если так таблица должна быть изменена. Все типы имеют специальность?

  3. Что касается DateOfHiring и YearsOfService, продолжительность службы может быть выведена текущая дата и DateOfHiring.

  4. Я не вижу способа, чтобы отключить штатный сотрудник. Что происходит, когда они прекращаются? Сбросив свои записи-не очень хорошее решение. Вы можете рассмотреть вопрос о добавлении даты расторжения в таблицу.

2
ответ дан 30 января 2011 в 08:01 Источник Поделиться