Р исунок 7.4 – Окно добавления/ редактирования студента



При выборе вкладки пропуски студента мы можем увидеть все имеющиеся у него пропуски с указанием даты, количества и причины пропусков (рисунок 7.5).

Р исунок 7.5 – Пропуски студента

Вкладка добавления пропусков студента имеет вид (рисунок 7.6):

Р исунок 7.6 – Добавление пропусков студента

Полученную таблицу пропусков выбранного студента можно сохранить в файл программы Excel (рисунок 7.7).

Р исунок 7.7 – Окно сохранения файла

Вид файла с пропусками в программе Excel (рисунок 7.8)

Р исунок 7.8 – Файл с пропусками

Удаление также работает (рисунок 7.9).

Р исунок 7.8 – Удаление пропусков студента


ПРИЛОЖЕНИЕ А

 

Правила генерации отношений по диаграммам ER-типа

ПРАВИЛО 1. Если показатель кардинальности бинарной связи равен 1:1 и класс принадлежности обеих сущностей является обязательным, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из двух сущностей.

ПРАВИЛО 2. Если показатель кардинальности бинарной связи равен 1:1 и класс принадлежности одной сущности является обязательным, а другой — необязательным, то необходимо построение двух отношений. Под каждую сущность необходимо выделение одного отношения, при этом ключ сущности должен служить первичным ключом для соответствующего отношения. Кроме того, ключ сущности, для которой класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности.

ПРАВИЛО 3. Если показатель кардинальности бинарной связи равен 1:1 и класс принадлежности ни одной сущности не является обязательным, то необходимо использовать три отношения: по одному для каждой сущности, ключи которых служат в качестве первичных в соответствующих отношениях, и одного для связи. Среди своих атрибутов отношение, выделяемое связи, будет иметь по одному ключу сущности от каждой сущности.

ПРАВИЛО 4. Если показатель кардинальности бинарной связи равен 1: n и класс принадлежности n-связной сущности является обязательным, то достаточным является использование двух отношений, по одному на каждую сущность, при условии, что ключ сущности каждой сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен как атрибут в отношение, отводимое n-связной сущности.

ПРАВИЛО 5. Если показатель кардинальности бинарной связи равен 1: n и класс принадлежности n‑связной сущности является необязательным, то необходимо формирование трех отношений: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одного отношения для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.

ПРАВИЛО 6. Если показатель кардинальности бинарной связи равен m : n, то для хранения данных необходимо три отношения: по одному для каждой сущности, причем ключ каждой сущности используется в качестве первичного ключа соответствующего отношения, и одного отношения для связи. Последнее отношение должно иметь в числе своих атрибутов ключ сущности каждой сущности.


 

 

ПРИЛОЖЕНИЕ Б

 

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

- первая нормальная форма (1NF);

- вторая нормальная форма (2NF);

- третья нормальная форма (3NF);

- нормальная форма Бойса-Кодда (BCNF);

- четвертая нормальная форма (4NF);

- пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

1НФ - таблица находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. (Любое поле таблицы содержит неделимую информацию и в таблице определен первичный ключ).

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

Если таблица в 1 НФ имеет простой первичный ключ, то она автоматически находится и во 2 НФ.

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

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

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

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

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

Теперь можно дать определения высших нормальных форм. И сначала будет дано определение для последней из предложенных - 5НФ.

5НФ - Таблица находится в пятой нормальной форме тогда и только тогда, когда в каждой ее полной декомпозиции все проекции содержат возможный ключ. Таблица, не имеющая ни одной полной декомпозиции, также находится в 5НФ.

4НФ - Четвертая нормальная форма является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций. Весьма не просто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы в 5НФ.

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


 

ПРИЛОЖЕНИЕ В

 

Содержание файла studentpass.sql

-- MySQL Script generated by MySQL Workbench

-- Sun Jan 14 22:51:43 2018

-- Model: New Model Version: 1.0

-- MySQL Workbench Forward Engineering

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;

SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;

SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

-- -----------------------------------------------------

-- Schema mydb

-- -----------------------------------------------------

-- -----------------------------------------------------

-- Schema studentpass

-- -----------------------------------------------------

CREATE SCHEMA IF NOT EXISTS `studentpass` DEFAULT CHARACTER SET utf8 ;

USE `studentpass` ;

-- -----------------------------------------------------

-- Table `studentpass`.`faculty`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `studentpass`.`faculty` (

`f_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,

`f_name` VARCHAR(40) NULL DEFAULT NULL,

PRIMARY KEY (`f_id`),

UNIQUE INDEX `f_id_UNIQUE` (`f_id` ASC))

ENGINE = InnoDB

DEFAULT CHARACTER SET = utf8;

-- -----------------------------------------------------

-- Table `studentpass`.`group`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `studentpass`.`group` (

`g_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,

`g_name` VARCHAR(6) NULL DEFAULT NULL,

`f_id` INT(10) UNSIGNED NOT NULL,

PRIMARY KEY (`g_id`),

UNIQUE INDEX `g_id_UNIQUE` (`g_id` ASC),

INDEX `fk_group_faculty1_idx` (`f_id` ASC),

CONSTRAINT `fk_group_faculty1`

FOREIGN KEY (`f_id`)

REFERENCES `studentpass`.`faculty` (`f_id`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB

DEFAULT CHARACTER SET = utf8;

-- -----------------------------------------------------

-- Table `studentpass`.`student`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `studentpass`.`student` (

`s_id` INT(11) NOT NULL AUTO_INCREMENT,

`s_fam` VARCHAR(30) NULL DEFAULT NULL,

`s_name` VARCHAR(15) NULL DEFAULT NULL,

`s_otch` VARCHAR(30) NULL DEFAULT NULL,

`g_id` INT(10) UNSIGNED NOT NULL,

PRIMARY KEY (`s_id`),

INDEX `fk_student_group1_idx` (`group_g_id` ASC),

CONSTRAINT `fk_student_group1`

FOREIGN KEY (`group_g_id`)

REFERENCES `studentpass`.`group` (`g_id`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB

DEFAULT CHARACTER SET = utf8;

-- -----------------------------------------------------

-- Table `studentpass`.`pass`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `studentpass`.`pass` (

`s_id` INT(11) NOT NULL,

`p_date` DATE NOT NULL,

`p_ammount` INT(11) NULL DEFAULT NULL,

`p_reason` ENUM('0', '1') NULL DEFAULT NULL,

PRIMARY KEY (`s_id`, `p_date`),

INDEX `fk_pass_student1_idx` (`s_id` ASC),

CONSTRAINT `fk_pass_student1`

FOREIGN KEY (`s_id`)

REFERENCES `studentpass`.`student` (`s_id`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB

DEFAULT CHARACTER SET = utf8;

SET SQL_MODE=@OLD_SQL_MODE;

SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;


 

ПРИЛОЖЕНИЕ Г


Дата добавления: 2022-12-03; просмотров: 23; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!