Дизайн базы данных для школьной системы

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

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

Я использую 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
);

 Структура сущностей /отношений

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

31 голос | спросил Sergio Tapia 29 Jpm1000000pmSat, 29 Jan 2011 19:30:59 +030011 2011, 19:30:59

7 ответов


23

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

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

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

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

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

ответил nhinkle 30 Jpm1000000pmSun, 30 Jan 2011 12:51:48 +030011 2011, 12:51:48
11

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

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

  • Глядя на ваш ERD, есть места, где он не может добраться до 3NF (который является уровнем нормализации базы данных, к которому вы должны стремиться, когда это возможно)

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

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

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

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

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

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

ответил agentile 29 Jpm1000000pmSat, 29 Jan 2011 21:07:44 +030011 2011, 21:07:44
10

Комментарии

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

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

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

  4. Относительно персонала. Как Персонал, я бы сохранил личные данные Студента в таблице Лица. Заметка. Я все равно сохранил бы отдельную таблицу (или представление) для Staff /Student, у которой есть ссылка на таблицу Person.

ответил Martin York 29 Jpm1000000pmSat, 29 Jan 2011 20:11:14 +030011 2011, 20:11:14
4

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

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

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

Таблица наблюдений: Observation_ID, Student_ID, Observation_Date, Observation, Staff_ID

  1. Я согласен с тем, что должна быть отдельная таблица «Contact_Info». Кроме того, я уверен, что вы захотите время от времени отправлять студенту (или родителям студента). Для этой цели я бы включил таблицу «Адреса». Я не буду притворяться, что знаю, как это работает в Боливии, но в штатах школы любят рассылать карточки с отчетами (хотя родители ТАКЖЕ могут больше отслеживать продвижение своих учеников через Интернет ...).

  2. Оклады сотрудников могут измениться. Хотя вы можете решить, что приемлемо перезаписать это значение, это еще одна область, где правильная нормализация указывает таблицу «Оклады сотрудников», которая включает в себя поля для идентификатора, зарплаты и эффективности.

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

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

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

ответил XIVSolutions 30 Jpm1000000pmSun, 30 Jan 2011 12:36:26 +030011 2011, 12:36:26
2

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

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

ответил Eric Bréchemier 29 Jpm1000000pmSat, 29 Jan 2011 20:24:56 +030011 2011, 20:24:56
2

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

Таблица персонала

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

    contact_id, contact_name, relationship, contact_number, contact_address, fk=staff_id
    
  2. Может ли Штат иметь более одного StaffType? Как учитель может быть тренером? Если это так, таблица должна быть изменена. У всех типов есть специальность?

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

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

ответил 30 Jam1000000amSun, 30 Jan 2011 11:48:25 +030011 2011, 11:48:25
1

Все таблицы используют автоматически назначенные последовательности как ключи, это не правильное моделирование данных. Многие люди делают это и забывают о реальном /деловом /реальном мире Первичные ключи . Вы не хотите разрешать нескольким пользователям /областям /темам с тем же именем, поэтому вы должны добавить уникальные ограничения в User.username, Area.name, Subject.name, Subject.Abbreviation и т. Д.

ID в SubjectGrade бесполезен, он никогда не используется /не упоминается, логический ключ IDGrade,IDSubject.

Аналогично для ScoreRecord: IDSubject, IDStudent вместо ID

ответил dnoeth 28 MarpmMon, 28 Mar 2016 15:03:59 +03002016-03-28T15:03:59+03:0003 2016, 15:03:59

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132