Как я и обещал, теперь у нас будет более сложная структура данных. Некоторое время обдумывая, что можно предложит вашему вниманию, я решил остановиться на следующей идее – мы рассмотрим систему для работы приемной комиссии.
По идее у нас будет список абитуриентов, которые поступают на определенную специальность. Для каждой специальности существует определенный список предметов, по которым абитуриент сдает экзамены. Само собой, что оценки за сдачу предмета сохраняются.
Конечно же возникает сразу соблазн расширить нашу систему еще больше – например, ввести проходной балл на каждую специальность, ввести возможность изменять список сдаваемых предметов для специальности во времени – каждый год список может быть новым. Ну и так далее. Но надо соблюсти меру – тем более, что у нас и так получится неплохая система, которая будет включать в себя достаточно распространенные отношения между сущностями. Так что нарисуем схему нашей базы данных:

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

 

    APPLICANT – таблица со списком абитуриентов

  • APPLICANT_ID – уникальный идентификатор, который будет автоматически создаваться базой данных.
  • PROFESSION_ID – специальность, на которую собирается поступать абитуриент. Здесь важно обратить внимание, что у нас появилась связь с таблицей PROFESSION. Каждый абитуриент поступает на определенную специальность. Но надо также отметить, что много студентов могут поступать на одну и ту же специальность. (Можно видеть, что будет сгенерирован Foreign Key – (FK)).
  • LAST_NAME, FIRST_NAME, MIDDLE_NAME — соответственно фамилия, имя, отчество.
  • ENTRANCE_YEAR – год поступления абитуриента.
    PROFESSION – таблица специальностей

  • PROFESSION_ID — уникальный идентификатор, который будет автоматически создаваться базой данных
  • PROFESSION_NAME – название специальности
    SUBJECT — список предметов, который будут сдавать абитуриенты

  • SUBJECT_ID — уникальный идентификатор, который будет автоматически создаваться базой данных.
  • SUBJECT_NAME – наименование предмета
    APPLICANT_RESULT — таблица с результатами сдачи экзаменов

  • APPLICANT_RESULT_ID — уникальный идентификатор, который будет автоматически создаваться базой данных.
  • APPLICANT_ID – ссылка на абитуриента. Здесь у нас тоже есть связь – для одного студента может быть много результатов. (Можно видеть, что будет сгенерирован Foreign Key – (FK)).
  • SUBJECT_ID – ссылка на предмет, который сдавал абитуриент. Здесь мы можем вести ограничение – один абитуриент не может сдавать один и тот же предмет дважды. (Можно видеть, что будет сгенерирован Foreign Key – (FK)).
  • MARK – оценка за экзамен
    SPECIALITY_SUBJECT — таблица связи между предметами и специальностями

  • SPECIALITY_SUBJECT_ID — уникальный идентификатор, который будет автоматически создаваться базой данных.
  • PROFESSION_ID – ссылка на специальность. (Можно видеть, что будет сгенерирован Foreign Key – (FK)).
  • SUBJECT_ID – ссылка на предмет. (Можно видеть, что будет сгенерирован Foreign Key – (FK)).

Т.к. для одной специальности надо сдавать много предметов и одновременно один предмет может сдаваться для нескольких специальностей, то мы получаем достаточно сложную связь – многие ко многим. И такая связь реализуется с помощью дополнительной таблицы, в которой прописываются связи между предметами и специальностями. Думаю, что разобраться здесь не очень сложно.
Как видим, несмотря на то, что у нас не так уж много таблиц, связей у нас предостаточно. Причем есть разные связи – и многие ко многим, и один к одному.
Ниже приведен SQL-скрипт, который можно запустить на MySQL для генерации всех наших таблиц. Скопируйте и запишите в файлApplicant.sql. Причем со всеми необходимыми индексами и связями. Для запуска можно набрать такую команду:

 

mysql –u root –p < Applicant.sql

Ну и сам скрипт. Как нормальный разработчик, я нарисовал всю схему при помощи пакета, а потом получил SQL. Советую пользоваться такими штуками – их достаточно много. Мне лично нравится ERStudio. Хотя и PowerDesigner тоже неплохо.

Applicant.sql

Ну что же – база данных у нас есть, и мы готовы переходить к следующему шагу – созданию классов на уровне Persistence Layer. Здесь мы познакомимся с наиболее популярным пакетом – Hibernate. Итак, вперед — Часть 16 — Hibernate. Начало пути.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.