0

База данных для школы

Построение программы, обеспечивающей взаимодействие с ней в режиме диалога для завуча школы. Инфологическая модель базы данных школы. Создание таблиц, запросов и отчетов. Главное интерфейсное окно. Формы "Редактирование данных " и "Ввод преподавателя".

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 21.01.2015
Размер файла 780,4 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Процесс автоматизации обработки информации обычно рассматривается с учетом двух компонентов: данных и алгоритма обработки. Сформулированы стандартные требования к организации данных:

интеграция данных, в этом случае создается динамическая модель предметной области, в рамках которой работает автоматизированная информационная система;

максимально возможная независимость прикладных программ от данных.

Выполнение этих требований привело к появлению единого блока данных (базы данных (БД) и разработке одной управляющей программы для манипулирования данными на физическом уровне (системы управления данными СУБД).

Система управления базами данных (СУБД) основывается на использовании определенной модели данных, отражающих взаимосвязи объектов. Современная классификация СУБД предусматривает реализацию иерархических, сетевых и реляционных моделей данных.

Реляционная модель СУБД основывается на математическом понятии отношения, а общая структура данных представляется в виде таблицы, в которой каждая строка значений соответствует логической записи, а заголовки столбцов являются характеристиками объектов, информацию о которых необходимо хранить в БД.

Процесс проектирования БД представляет собой последовательность перехода от неформального словесного описания информационной структуры предметной области к формальному описанию объектов предметной области в терминах некоторой модели.

В общем случае можно выделить следующие этапы проектирования:

системный анализ и словесное описание информационных объектов предметной области;

проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некоторой семантической модели;

даталогическое или логическое проектирование БД, т.е. описание БД в терминах принятой даталогической модели данных;

физическое проектирование БД, т.е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

В качестве системы управления базой данных в данной курсовой работе используется СУБД MS Access.

2. Анализ предметной области

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

Для каждого учителя в БД должны храниться сведения о предметах, которые он преподает, номере кабинета, который за ним закреплен, номера классов, в которых он ведет занятия, номере урока и дне, когда он ведет уроки. Существуют учителя, которые не имеют собственного кабинета. Об учениках должны храниться следующие сведения: фамилия и имя, в каком классе учится, какая оценка по каждому предмету получена. Ученик может исправить полученную оценку. Завуч может добавить информацию о новом учителе или ученике, а также удалить – выбывших.

Завучу могут потребоваться следующие сведения:

какой предмет будет в заданном классе, например, во вторник на заданном уроке;

кто из учителей преподает в заданном классе;

в коком кабинете будет 5-й урок в среду у некоторого класса;

в каких классах преподает учитель заданный предмет;

расписание на заданный день недели для класса.

Завуч может вносить следующие изменения:

вносить информацию о новом учителе;

удалять запись об ученике;

изменить оценку ученику.

Необходимо предусмотреть возможность выдачи справки о количестве учеников в данном классе и отчета о работе школы (количество учителей по предметам, количество кабинетов, число учеников в каждом классе, число двоечников, хорошистов и отличников).

Для определения схемы данных проектируемой базы данных, то есть построения ее инфологической модели, необходимо определить сущности и связи БД. С помощью сущности моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Сущность соответствует некоторому классу однотипных объектов, поэтому предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного представителя класса. Между сущностями могут быть установлены связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют друг с другом. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).

Рис. Инфологическая модель БД школы

4. Нормализация БД

Проектирование схемы БД может быть выполнено двумя путями:

путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД, заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;

путем синтеза, т.е. путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

5-я (5 NF) или форма проекции-соединения (PJNF).

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

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

В проектируемой БД имеется отношение расписание, которое имеет вид:

Рисунок 3 – Схема базы данных «Школа»

4.2 Нормализация отношений

Проведем нормализацию полученных отношений. Проверим отношения на первую нормальную форму (1НФ). Отношение находится в 1НФ, если все его атрибуты простые. Рассматривая на примере таблицы «Учителя», мы видим, что атрибут «ФИО учителя» является составным, так как он состоит из трёх компонентов, то есть его можно разделить на 3 независимых атрибута, так как в данной БД эти компоненты по отдельности не используются, то мы принимаем данный атрибут за простой. Все остальные атрибуты, являются простыми.

Проверим отношения на вторую нормальную форму (2НФ). Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа. Например, в таблице «Расписание», неключевой атрибут «Номер урока» не зависит от части составного ключа в целом, а зависит от него в целом .

Читайте также:  Где взять код пароль для обновления айфона

Проверим отношения на третью нормальную форму (3НФ). Отношение находится в 3НФ, если оно находится в 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа, другими словами не зависит функционально от любого другого не ключевого поля. Транзитивная зависимость отсутствует, так как неключевые атрибуты не зависят друг от друга.

5 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

5.1 Составление форм, запросов и отчетов

Доступ ко всем компонентам, а именно, формам и отчетам осуществляется через окно главной кнопочной формы, которая запускается автоматически при открытии базы данных.

Рисунок 4 – Главная кнопочная форма

В БД содержатся следующие таблицы (рис.5-11):

Рисунок 5 – Таблица «Учителя»

Рисунок 6 – Таблица «Кабинет»

Рисунок 7 – Таблица «Кружки»

Рисунок 8 – Таблица «Занятия»

Рисунок 9 – Таблица «Ученики»

Рисунок 10 – Таблица «Расписание»

Рисунок 11 – Таблица «Классы»

Рисунок 12 – форма содержащая информацию о учителях

Рисунок 13 – форма для кабинетов

Рисунок 14 – форма для кружков

Рисунок 15 – форма для классов

Рисунок 16 – форма для расписания

Рисунок 17 – запрос «Учителя с высшей категорией»

Рисунок 18 – запрос «MAX и MIN педагогическим стажем»

Рисунок 19 – запрос «общее количество часов в год»

Создадим запросы с параметром:

Рисунок 20 – запрос «Кружки проходящие в понедельник»

Рисунок 21 – Перекрестный запрос «Расписание кружков и учителей»

Рисунок 22 – Перекрестный запрос «Расписание»

Рисунок 23 – отчет «Кружки».

Рисунок 24 – отчет «Расписание уроков».

Рисунок 25 – отчет «Наличие и отсутствие классного руководства».

Рисунок 26 – отчет «Классы».

Рисунок 27 – отчет «Кабинеты».

Рисунок 28 – отчет «Ученики».

5.2 Защита данных

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

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

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

В-третьих, для некоторых таблиц необходимо обеспечить выборочный доступ к ее столбцам.

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

Схема доступа к данным во всех реляционных СУБД выглядит примерно одинаково и базируется на трех принципах:

Пользователи СУБД рассматриваются как основные действующие лица, желающие получить доступ к данным. СУБД от имени конкретного пользователя выполняет операции над базой данных, то есть добавляет строки в таблицы (INSERT), удаляет строки (DELETE), обновляет данные в строках таблицы (UPDATE). Она делает это в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом базы данных.

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

Привилегии (priveleges) — это операции, которые разрешено выполнять пользователю над конкретными объектами. Например, пользователю может быть разрешено выполнение над таблицей операций SELECT (ВЫБРАТЬ) и INSERT (ВКЛЮЧИТЬ).

Таким образом, в СУБД авторизация доступа осуществляется с помощью привилегий. Установление и контроль привилегий — прерогатива администратора базы данных. Привилегии устанавливаются и отменяются специальными операторами языка SQL — GRANT (РАЗРЕШИТЬ) и REVOKE (ОТМЕНИТЬ). Оператор GRANT указывает конкретного пользователя, который получает конкретные привилегии доступа к указанной таблице. Например, оператор

GRANT SELECT, INSERT ОN Клиенты TO Битов

устанавливает привилегии пользователю Битов на выполнение операций выбора и включения над таблицей Клиенты. Как видно из примера, оператор GRANT устанавливает соответствие между операциями, пользователем и объектом базы данных (таблицей в данном случае).

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

REVOKE INSERT ON Клиенты FROM Битов

Конкретный пользователь СУБД опознается по уникальному идентификатору (user-id). Любое действие над базой данных, любой оператор языка SQL выполняется не анонимно, но от имени конкретного пользователя. Идентификатор пользователя определяет набор доступных объектов базы данных для конкретного физического лица или группы лиц. Однако он ничего не сообщает о механизме его связи с конкретным оператором SQL. Например, когда запускается интерактивный SQL, как СУБД узнает, от имени какого пользователя осуществляется доступ к данным? Для этого в большинстве СУБД используется сеанс работы с базой данных. Для запуска на компьютере-клиенте программы переднего плана (например, интерактивного SQL) пользователь должен сообщить СУБД свой идентификатор и пароль. Все операции над базой данных, которые будут выполнены после этого, СУБД свяжет с конкретным пользователем, который запустил программу.

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

Читайте также:  Зарядка аккумулятора без ноутбука

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

1. Проектирование БД «Школа»

1.1 Проектирование модели реальной БД на примере создания

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

1 – 4 : Основные объекты БД

5 – 8 : Объекты, с помощью которых осуществляется связь основных объектов друг с другом:

5 – 6 : Связи между объектами, которые реализуются с помощью дополнительных таблиц,

7 – 8 : Связи между объектами, которые реализуются с помощью прямых связей между таблицами.

На рис.1.1 стрелки, соединяющие объекты БД, помечены значками 1 и ¥. Это означает вид связи один-ко-многим. Например, в одном классе учатся много учеников или, один ученик получает много оценок.

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

1.2 Разработка структуры таблиц и типов полей в БД «Школа»

Мастер подстановки из таблицы Учителя.

Мастер подстановки из таблицы Класс

Мастер подстановки из таблицы Учителя

Мастер подстановки из таблицы Предмет

Мастер подстановки из таблицы Класс

Мастер подстановки из таблицы Ученики

Мастер подстановки из таблицы Предмет

Мастер подстановки на основе фиксированного набора данных

Мастер подстановки на основе фиксированного набора данных

1.3 Допустимые данные для таблиц БД «Школа»

Хотя мы и так довольно сильно сократили количество объектов в нашей БД «Школа», но если мы будем вносить в таблицы реальное количество классов в школе (10-40), учеников в них (30), изучаемых предметов и учителей, читающих эти предметы, то наша БД станет очень большой и все время придется потратить только на ввод данных в нее. Поэтому мы и здесь сократим свою работу до минимума.

В нашей школе будет 3 класса: 11-А, 11-Б и 11-В (в вашей могут быть совершенно другие классы, например, 5-Ё). В каждом классе учится по 5 учеников, в школе работает 6 учителей (3 классных руководителя и 3 учителя-предметника) и дети изучают в каждом классе по 5 предметов. Один и тот же предмет в разных классах могут вести разные учителя и один и тот же учитель может читать разные предметы.

Для того чтобы мы знали, какие конкретно данные вводить в таблицы БД, составим списки предметов (табл. 1.2), которые будут читаться в разных классах (у нас обучение профильное и в разных классах читаются разные предметы, а у вас это могут быть просто разные классы – 5, 7, 10)

класс с углубленным изучением химии

класс с углубленным изучением физики

1.4 Создание таблиц БД «Школа» и связей между ними

Откроем программу Ms ACCESS, выберем место на диске, где будет храниться наша БД, назовем ее Школа.mdb и приступим к созданию таблиц.

Сначала будем создавать таблицы, при построении которых не используется Мастер подстановки (табл.1.1). Это таблицы Учителя и Предмет.

В главном окне БД выбираем Создание таблицы в режиме конструктора (рис.1.2) и делаем такие поля для таблицы Учителя (рис.1.3):

Поле №_учителя делаем ключевым – выделяем его и нажимаем кнопку Ключевое поле на панели инструментов (ПИ). Значения для этого поля вводятся автоматически при заполнении таблицы и не повторяются, даже если какая-то запись будет удалена.

Тип поля Класное_руководство устанавливаем Логический, значение – «Да» или «Нет». При вводе данных достаточно поставить галочку в этом поле.

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

Таблицу Учителя можно сразу и заполнить данными, чтобы продемонстрировать потом работу Мастера подстановки. Переходим из режима конструктора в режим таблицы и вносим данные (рис.1.4):

Аналогично создаем таблицу Предмет (рис.1.5 и 1.6). Названия предметов берем из таблицы 1.2.

Теперь создадим таблицу Класс. Тоже в главном окне БД выбираем Создание таблицы в режиме конструктора и делаем такие поля (Рис.1.7):

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

Например, при вводе названия класса можно написать: 11А, 11-А, 11 а и т. п. Для нас это все один и тот же 11-А класс, а для БД – это различные данные. Чтобы избежать такого разночтения и используется Мастер подстановки.

1. В списке типов полей выбираем Мастер подстановки (рис.1.7)

2. В появившемся окне переключатель устанавливаем в позицию Объект «столбец подстановки» будет использовать значения из таблицы или запроса. (рис.1.8)

Читайте также:  Герои 6 код ошибки 2

3. В окне (рис.1.9) выбираем таблицу, из которой будем брать данные. Сейчас это таблица – Учителя.

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

Здесь еще можно выбрать столбец Классное_руководство, чтобы было сразу видно, кто из учителей является классным руководителем, чтобы учителю-предметнику не «навязать» еще и классное руководство! Программа ACCESS будет сохранять в таблице Класс номер учителя, а на экран при работе с этой таблицей выведет фамилию.

5. На рис. 1.10 видно, как будет выглядеть наш столбец подстановки:

6. Нажимаем кнопку Готово, переходим в режим таблицы и смотрим, как это работает (рис.1.11 и 1.12):

Теперь сформируем и остальные таблицы. Данные в них можно внести и после того, как создадим все таблицы.

Таблица Ученики. Для облегчения дальнейшего ввода данных в нее, в полях Дата_рождения и Телефон применим шаблоны – формат поля и маску ввода (см. Приложение на стр.47) (Рис. 1.13 и 1.14):

Вот готовая таблица Ученики (рис.1.15):

Теперь займемся таблицей Преподает. Эта таблица не содержит ключевого поля и все значения в ней определяются Мастером подстановки для полей №_учителя, №_предмета и Класс (табл.1.1). Вот заполненная таблица Преподает с сортировкой данных по классам (рис.1.16) и по учителям (рис.1.17):

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

225=количество учеников * количество предметов в классе * количество периодов обучения

Период обучения – 1 семестр, 2 семестр, год. Таким образом, в нашей БД будут находиться только семестровые и годовые оценки учеников по всем предметам.

Поля №_ученика и №_предмета формируются с помощью Мастера подстановки так же, как и в предыдущих таблицах. А вот для полей Период и Оценки, мы создадим фиксированные наборы данных:

1. В столбце Тип данных Конструктора таблицы выбираем Мастер подстановки.

2. В открывшемся окне (рис. 1.18) переключатель устанавливаем возле «Будет введен фиксированный набор значений»

3. В следующем окне (рис.1.19) заполняем нужные нам данные. И получим «внутренний» для этой таблицы столбец подстановки.

Аналогично можно поступить и с полем Оценки. Обратите внимание, что в демонстрационной БД, которую Вы получили вместе с этой книгой используется 5-ти бальная система оценок. Учителям в Украине оценки нужно поменять на 12-ти бальную систему.

Когда начнем вводить информацию в таблицу, то в поле Период возникнет раскрывающийся список с периодами обучения (рис.1.20):

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

А вот пример заполненной таблицы для первого ученика (рис.1.21):

Еще 15 раз по столько – и золотой ключик у вас в кармане!

🙂 – Дети, если вы не будете хорошо учиться, то вам всю жизнь придется заполнять БД!

На самом первом этапе работы над БД «Школа» нужно просто создать эти таблицы. Заполнять данные лучше после того, как установлены и настроены все связи в таблицах.

1.5 Схема данных БД «Школа»

Перейдем в главное окно БД и в ПИ нажмем кнопку Схема данных . Появится соответствующее окно (рис.1.22). Если в процессе создания таблиц мы использовали Мастер подстановки, то Ms ACCESS самостоятельно установит нужные связи между полями в таблицах. Расположение таблиц в окне может быть другое. Вы можете для удобства сравнения с рисунком перетащить их, ухватившись за заголовок таблицы. Если на вашей схеме появилось меньше 6 таблиц, то недостающие таблицы нужно добавить. Нажмите правую кнопку мыши внутри окна схемы данных и выберите команду Добавить. Если же у вас появились лишние таблицы с именами Класс1 или Преподает3, то их нужно удалить, т. к. они не дадут нам построить запросы. Для удаления лишней таблицы, нужно сначала удалить связи, которые у нее есть с другими таблицами. Нажимаем правую кнопку мыши на линии связи и выбираем команду Удалить. Если же между таблицами нет линий связи, то вы не использовали мастер подстановки. Связи можно установить и в окне Схема данных. Выделаем нужное поле в нужной таблице и перетягиваем его на другую таблицу.

Теперь изменим свойства связей в БД. Посмотрим на рис.1.1. Там на стрелках стоят значки 1 и ¥. Такие же значки нужно установить и в схеме данных.

1. На каждой линии связи нажимаем правую кнопку мыши и выбираем команду Изменить связь (рис.1.23)

2. В появившемся окне (рис.1.24) ставим флажок Обеспечение целостности данных и жмем ОК.

3. Получаем результат (рис.1.25) – в одном классе учиться много учеников.

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

Аналогичным образом устанавливаем все свойства связей между таблицами, кроме связи Учитель – Класс. Хотя в одном классе может быть только один классный руководитель, и один учитель может быть классным руководителем тоже только в одном классе, этот тип связи между таблицам Учитель и Класс мы установить не можем, т. к. есть еще и учителя-предметники. Поэтому не может быть совпадения количества записей в таблицах Класс и Учитель.

В результате должна получиться такая картинка (рис.1.26):

Всю основную работу по проектированию и созданию таблиц БД «Школа» мы сделали, а заполнять таблицы можно по мере наличия свободного времени!

admin

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

0

База данных для школы

Построение программы, обеспечивающей взаимодействие с ней в режиме диалога для завуча школы. Инфологическая модель базы данных школы. Создание таблиц, запросов и отчетов. Главное интерфейсное окно. Формы "Редактирование данных " и "Ввод преподавателя".

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 21.01.2015
Размер файла 780,4 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Процесс автоматизации обработки информации обычно рассматривается с учетом двух компонентов: данных и алгоритма обработки. Сформулированы стандартные требования к организации данных:

интеграция данных, в этом случае создается динамическая модель предметной области, в рамках которой работает автоматизированная информационная система;

максимально возможная независимость прикладных программ от данных.

Выполнение этих требований привело к появлению единого блока данных (базы данных (БД) и разработке одной управляющей программы для манипулирования данными на физическом уровне (системы управления данными СУБД).

Система управления базами данных (СУБД) основывается на использовании определенной модели данных, отражающих взаимосвязи объектов. Современная классификация СУБД предусматривает реализацию иерархических, сетевых и реляционных моделей данных.

Реляционная модель СУБД основывается на математическом понятии отношения, а общая структура данных представляется в виде таблицы, в которой каждая строка значений соответствует логической записи, а заголовки столбцов являются характеристиками объектов, информацию о которых необходимо хранить в БД.

Процесс проектирования БД представляет собой последовательность перехода от неформального словесного описания информационной структуры предметной области к формальному описанию объектов предметной области в терминах некоторой модели.

В общем случае можно выделить следующие этапы проектирования:

системный анализ и словесное описание информационных объектов предметной области;

проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некоторой семантической модели;

даталогическое или логическое проектирование БД, т.е. описание БД в терминах принятой даталогической модели данных;

физическое проектирование БД, т.е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

В качестве системы управления базой данных в данной курсовой работе используется СУБД MS Access.

2. Анализ предметной области

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

Для каждого учителя в БД должны храниться сведения о предметах, которые он преподает, номере кабинета, который за ним закреплен, номера классов, в которых он ведет занятия, номере урока и дне, когда он ведет уроки. Существуют учителя, которые не имеют собственного кабинета. Об учениках должны храниться следующие сведения: фамилия и имя, в каком классе учится, какая оценка по каждому предмету получена. Ученик может исправить полученную оценку. Завуч может добавить информацию о новом учителе или ученике, а также удалить – выбывших.

Завучу могут потребоваться следующие сведения:

какой предмет будет в заданном классе, например, во вторник на заданном уроке;

кто из учителей преподает в заданном классе;

в коком кабинете будет 5-й урок в среду у некоторого класса;

в каких классах преподает учитель заданный предмет;

расписание на заданный день недели для класса.

Завуч может вносить следующие изменения:

вносить информацию о новом учителе;

удалять запись об ученике;

изменить оценку ученику.

Необходимо предусмотреть возможность выдачи справки о количестве учеников в данном классе и отчета о работе школы (количество учителей по предметам, количество кабинетов, число учеников в каждом классе, число двоечников, хорошистов и отличников).

Для определения схемы данных проектируемой базы данных, то есть построения ее инфологической модели, необходимо определить сущности и связи БД. С помощью сущности моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Сущность соответствует некоторому классу однотипных объектов, поэтому предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного представителя класса. Между сущностями могут быть установлены связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют друг с другом. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).

Рис. Инфологическая модель БД школы

4. Нормализация БД

Проектирование схемы БД может быть выполнено двумя путями:

путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД, заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;

путем синтеза, т.е. путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

5-я (5 NF) или форма проекции-соединения (PJNF).

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

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

В проектируемой БД имеется отношение расписание, которое имеет вид:

Рисунок 3 – Схема базы данных «Школа»

4.2 Нормализация отношений

Проведем нормализацию полученных отношений. Проверим отношения на первую нормальную форму (1НФ). Отношение находится в 1НФ, если все его атрибуты простые. Рассматривая на примере таблицы «Учителя», мы видим, что атрибут «ФИО учителя» является составным, так как он состоит из трёх компонентов, то есть его можно разделить на 3 независимых атрибута, так как в данной БД эти компоненты по отдельности не используются, то мы принимаем данный атрибут за простой. Все остальные атрибуты, являются простыми.

Проверим отношения на вторую нормальную форму (2НФ). Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа. Например, в таблице «Расписание», неключевой атрибут «Номер урока» не зависит от части составного ключа в целом, а зависит от него в целом .

Читайте также:  Захват видео с видеомагнитофона на компьютер программа

Проверим отношения на третью нормальную форму (3НФ). Отношение находится в 3НФ, если оно находится в 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа, другими словами не зависит функционально от любого другого не ключевого поля. Транзитивная зависимость отсутствует, так как неключевые атрибуты не зависят друг от друга.

5 ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

5.1 Составление форм, запросов и отчетов

Доступ ко всем компонентам, а именно, формам и отчетам осуществляется через окно главной кнопочной формы, которая запускается автоматически при открытии базы данных.

Рисунок 4 – Главная кнопочная форма

В БД содержатся следующие таблицы (рис.5-11):

Рисунок 5 – Таблица «Учителя»

Рисунок 6 – Таблица «Кабинет»

Рисунок 7 – Таблица «Кружки»

Рисунок 8 – Таблица «Занятия»

Рисунок 9 – Таблица «Ученики»

Рисунок 10 – Таблица «Расписание»

Рисунок 11 – Таблица «Классы»

Рисунок 12 – форма содержащая информацию о учителях

Рисунок 13 – форма для кабинетов

Рисунок 14 – форма для кружков

Рисунок 15 – форма для классов

Рисунок 16 – форма для расписания

Рисунок 17 – запрос «Учителя с высшей категорией»

Рисунок 18 – запрос «MAX и MIN педагогическим стажем»

Рисунок 19 – запрос «общее количество часов в год»

Создадим запросы с параметром:

Рисунок 20 – запрос «Кружки проходящие в понедельник»

Рисунок 21 – Перекрестный запрос «Расписание кружков и учителей»

Рисунок 22 – Перекрестный запрос «Расписание»

Рисунок 23 – отчет «Кружки».

Рисунок 24 – отчет «Расписание уроков».

Рисунок 25 – отчет «Наличие и отсутствие классного руководства».

Рисунок 26 – отчет «Классы».

Рисунок 27 – отчет «Кабинеты».

Рисунок 28 – отчет «Ученики».

5.2 Защита данных

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

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

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

В-третьих, для некоторых таблиц необходимо обеспечить выборочный доступ к ее столбцам.

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

Схема доступа к данным во всех реляционных СУБД выглядит примерно одинаково и базируется на трех принципах:

Пользователи СУБД рассматриваются как основные действующие лица, желающие получить доступ к данным. СУБД от имени конкретного пользователя выполняет операции над базой данных, то есть добавляет строки в таблицы (INSERT), удаляет строки (DELETE), обновляет данные в строках таблицы (UPDATE). Она делает это в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом базы данных.

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

Привилегии (priveleges) — это операции, которые разрешено выполнять пользователю над конкретными объектами. Например, пользователю может быть разрешено выполнение над таблицей операций SELECT (ВЫБРАТЬ) и INSERT (ВКЛЮЧИТЬ).

Таким образом, в СУБД авторизация доступа осуществляется с помощью привилегий. Установление и контроль привилегий — прерогатива администратора базы данных. Привилегии устанавливаются и отменяются специальными операторами языка SQL — GRANT (РАЗРЕШИТЬ) и REVOKE (ОТМЕНИТЬ). Оператор GRANT указывает конкретного пользователя, который получает конкретные привилегии доступа к указанной таблице. Например, оператор

GRANT SELECT, INSERT ОN Клиенты TO Битов

устанавливает привилегии пользователю Битов на выполнение операций выбора и включения над таблицей Клиенты. Как видно из примера, оператор GRANT устанавливает соответствие между операциями, пользователем и объектом базы данных (таблицей в данном случае).

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

REVOKE INSERT ON Клиенты FROM Битов

Конкретный пользователь СУБД опознается по уникальному идентификатору (user-id). Любое действие над базой данных, любой оператор языка SQL выполняется не анонимно, но от имени конкретного пользователя. Идентификатор пользователя определяет набор доступных объектов базы данных для конкретного физического лица или группы лиц. Однако он ничего не сообщает о механизме его связи с конкретным оператором SQL. Например, когда запускается интерактивный SQL, как СУБД узнает, от имени какого пользователя осуществляется доступ к данным? Для этого в большинстве СУБД используется сеанс работы с базой данных. Для запуска на компьютере-клиенте программы переднего плана (например, интерактивного SQL) пользователь должен сообщить СУБД свой идентификатор и пароль. Все операции над базой данных, которые будут выполнены после этого, СУБД свяжет с конкретным пользователем, который запустил программу.

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

Читайте также:  Аудио конвектор в формат мр3

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

1. Проектирование БД «Школа»

1.1 Проектирование модели реальной БД на примере создания

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

1 – 4 : Основные объекты БД

5 – 8 : Объекты, с помощью которых осуществляется связь основных объектов друг с другом:

5 – 6 : Связи между объектами, которые реализуются с помощью дополнительных таблиц,

7 – 8 : Связи между объектами, которые реализуются с помощью прямых связей между таблицами.

На рис.1.1 стрелки, соединяющие объекты БД, помечены значками 1 и ¥. Это означает вид связи один-ко-многим. Например, в одном классе учатся много учеников или, один ученик получает много оценок.

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

1.2 Разработка структуры таблиц и типов полей в БД «Школа»

Мастер подстановки из таблицы Учителя.

Мастер подстановки из таблицы Класс

Мастер подстановки из таблицы Учителя

Мастер подстановки из таблицы Предмет

Мастер подстановки из таблицы Класс

Мастер подстановки из таблицы Ученики

Мастер подстановки из таблицы Предмет

Мастер подстановки на основе фиксированного набора данных

Мастер подстановки на основе фиксированного набора данных

1.3 Допустимые данные для таблиц БД «Школа»

Хотя мы и так довольно сильно сократили количество объектов в нашей БД «Школа», но если мы будем вносить в таблицы реальное количество классов в школе (10-40), учеников в них (30), изучаемых предметов и учителей, читающих эти предметы, то наша БД станет очень большой и все время придется потратить только на ввод данных в нее. Поэтому мы и здесь сократим свою работу до минимума.

В нашей школе будет 3 класса: 11-А, 11-Б и 11-В (в вашей могут быть совершенно другие классы, например, 5-Ё). В каждом классе учится по 5 учеников, в школе работает 6 учителей (3 классных руководителя и 3 учителя-предметника) и дети изучают в каждом классе по 5 предметов. Один и тот же предмет в разных классах могут вести разные учителя и один и тот же учитель может читать разные предметы.

Для того чтобы мы знали, какие конкретно данные вводить в таблицы БД, составим списки предметов (табл. 1.2), которые будут читаться в разных классах (у нас обучение профильное и в разных классах читаются разные предметы, а у вас это могут быть просто разные классы – 5, 7, 10)

класс с углубленным изучением химии

класс с углубленным изучением физики

1.4 Создание таблиц БД «Школа» и связей между ними

Откроем программу Ms ACCESS, выберем место на диске, где будет храниться наша БД, назовем ее Школа.mdb и приступим к созданию таблиц.

Сначала будем создавать таблицы, при построении которых не используется Мастер подстановки (табл.1.1). Это таблицы Учителя и Предмет.

В главном окне БД выбираем Создание таблицы в режиме конструктора (рис.1.2) и делаем такие поля для таблицы Учителя (рис.1.3):

Поле №_учителя делаем ключевым – выделяем его и нажимаем кнопку Ключевое поле на панели инструментов (ПИ). Значения для этого поля вводятся автоматически при заполнении таблицы и не повторяются, даже если какая-то запись будет удалена.

Тип поля Класное_руководство устанавливаем Логический, значение – «Да» или «Нет». При вводе данных достаточно поставить галочку в этом поле.

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

Таблицу Учителя можно сразу и заполнить данными, чтобы продемонстрировать потом работу Мастера подстановки. Переходим из режима конструктора в режим таблицы и вносим данные (рис.1.4):

Аналогично создаем таблицу Предмет (рис.1.5 и 1.6). Названия предметов берем из таблицы 1.2.

Теперь создадим таблицу Класс. Тоже в главном окне БД выбираем Создание таблицы в режиме конструктора и делаем такие поля (Рис.1.7):

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

Например, при вводе названия класса можно написать: 11А, 11-А, 11 а и т. п. Для нас это все один и тот же 11-А класс, а для БД – это различные данные. Чтобы избежать такого разночтения и используется Мастер подстановки.

1. В списке типов полей выбираем Мастер подстановки (рис.1.7)

2. В появившемся окне переключатель устанавливаем в позицию Объект «столбец подстановки» будет использовать значения из таблицы или запроса. (рис.1.8)

Читайте также:  Бесплатное телевидение через смарт тв

3. В окне (рис.1.9) выбираем таблицу, из которой будем брать данные. Сейчас это таблица – Учителя.

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

Здесь еще можно выбрать столбец Классное_руководство, чтобы было сразу видно, кто из учителей является классным руководителем, чтобы учителю-предметнику не «навязать» еще и классное руководство! Программа ACCESS будет сохранять в таблице Класс номер учителя, а на экран при работе с этой таблицей выведет фамилию.

5. На рис. 1.10 видно, как будет выглядеть наш столбец подстановки:

6. Нажимаем кнопку Готово, переходим в режим таблицы и смотрим, как это работает (рис.1.11 и 1.12):

Теперь сформируем и остальные таблицы. Данные в них можно внести и после того, как создадим все таблицы.

Таблица Ученики. Для облегчения дальнейшего ввода данных в нее, в полях Дата_рождения и Телефон применим шаблоны – формат поля и маску ввода (см. Приложение на стр.47) (Рис. 1.13 и 1.14):

Вот готовая таблица Ученики (рис.1.15):

Теперь займемся таблицей Преподает. Эта таблица не содержит ключевого поля и все значения в ней определяются Мастером подстановки для полей №_учителя, №_предмета и Класс (табл.1.1). Вот заполненная таблица Преподает с сортировкой данных по классам (рис.1.16) и по учителям (рис.1.17):

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

225=количество учеников * количество предметов в классе * количество периодов обучения

Период обучения – 1 семестр, 2 семестр, год. Таким образом, в нашей БД будут находиться только семестровые и годовые оценки учеников по всем предметам.

Поля №_ученика и №_предмета формируются с помощью Мастера подстановки так же, как и в предыдущих таблицах. А вот для полей Период и Оценки, мы создадим фиксированные наборы данных:

1. В столбце Тип данных Конструктора таблицы выбираем Мастер подстановки.

2. В открывшемся окне (рис. 1.18) переключатель устанавливаем возле «Будет введен фиксированный набор значений»

3. В следующем окне (рис.1.19) заполняем нужные нам данные. И получим «внутренний» для этой таблицы столбец подстановки.

Аналогично можно поступить и с полем Оценки. Обратите внимание, что в демонстрационной БД, которую Вы получили вместе с этой книгой используется 5-ти бальная система оценок. Учителям в Украине оценки нужно поменять на 12-ти бальную систему.

Когда начнем вводить информацию в таблицу, то в поле Период возникнет раскрывающийся список с периодами обучения (рис.1.20):

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

А вот пример заполненной таблицы для первого ученика (рис.1.21):

Еще 15 раз по столько – и золотой ключик у вас в кармане!

🙂 – Дети, если вы не будете хорошо учиться, то вам всю жизнь придется заполнять БД!

На самом первом этапе работы над БД «Школа» нужно просто создать эти таблицы. Заполнять данные лучше после того, как установлены и настроены все связи в таблицах.

1.5 Схема данных БД «Школа»

Перейдем в главное окно БД и в ПИ нажмем кнопку Схема данных . Появится соответствующее окно (рис.1.22). Если в процессе создания таблиц мы использовали Мастер подстановки, то Ms ACCESS самостоятельно установит нужные связи между полями в таблицах. Расположение таблиц в окне может быть другое. Вы можете для удобства сравнения с рисунком перетащить их, ухватившись за заголовок таблицы. Если на вашей схеме появилось меньше 6 таблиц, то недостающие таблицы нужно добавить. Нажмите правую кнопку мыши внутри окна схемы данных и выберите команду Добавить. Если же у вас появились лишние таблицы с именами Класс1 или Преподает3, то их нужно удалить, т. к. они не дадут нам построить запросы. Для удаления лишней таблицы, нужно сначала удалить связи, которые у нее есть с другими таблицами. Нажимаем правую кнопку мыши на линии связи и выбираем команду Удалить. Если же между таблицами нет линий связи, то вы не использовали мастер подстановки. Связи можно установить и в окне Схема данных. Выделаем нужное поле в нужной таблице и перетягиваем его на другую таблицу.

Теперь изменим свойства связей в БД. Посмотрим на рис.1.1. Там на стрелках стоят значки 1 и ¥. Такие же значки нужно установить и в схеме данных.

1. На каждой линии связи нажимаем правую кнопку мыши и выбираем команду Изменить связь (рис.1.23)

2. В появившемся окне (рис.1.24) ставим флажок Обеспечение целостности данных и жмем ОК.

3. Получаем результат (рис.1.25) – в одном классе учиться много учеников.

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

Аналогичным образом устанавливаем все свойства связей между таблицами, кроме связи Учитель – Класс. Хотя в одном классе может быть только один классный руководитель, и один учитель может быть классным руководителем тоже только в одном классе, этот тип связи между таблицам Учитель и Класс мы установить не можем, т. к. есть еще и учителя-предметники. Поэтому не может быть совпадения количества записей в таблицах Класс и Учитель.

В результате должна получиться такая картинка (рис.1.26):

Всю основную работу по проектированию и созданию таблиц БД «Школа» мы сделали, а заполнять таблицы можно по мере наличия свободного времени!

admin

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *