Создание информационной системы Учебные планы Вычитка часов (стр. 2 из 4)

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

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

Таблица находится в первой нормальной форме, если каждый её атрибут атомарен. Под выражением «атрибут атомарен» понимается, что атрибут может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц.

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

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

Таблица находится в третьей нормальной форме (3NF), если она находится во второй нормальной форме (2NF) и при этом любой ее не-ключевой атрибут зависит только от первичного ключа (Primary key, PK) (иначе говоря, один факт хранится в одном месте).

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A → B и B → C, где A – набор ключевых атрибутов (ключ), B и С – различные множества неключевых атрибутов.

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

Инфологическая модель

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

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

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

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

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

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

· правил именования и обозначения объектов ПО, атрибутов и связей;

· содержания и формата создаваемых ими документов.

База данных содержит четыре таблицы: Учебные планы, Группы, Предметы и Занятия. Таблицы связаны отношениями «один-ко-многим» как показано на ER-диаграмме:

Даталогическая модель

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

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

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

Не все виды связи существующие в предметной области можно отобразить даталогической моделью. Так большинство СУБД не обеспечивают поддержание связи типа М:М. В этом случае в даталогической модели вводится вспомогательный элемент, т.е. M:N разбивается на два отношения между исходными элементами и вспомогательными (1:M, 1:N).

Ниже приведен DDL-скрипт для создания базы данных:

SET SQL DIALECT 3;

SET NAMES WIN1251;

CREATE DATABASE 'LOCALHOST:C:\MySoft\UP\up.gdb'

USER 'SYSDBA' PASSWORD 'masterkey'

PAGE_SIZE 16384

DEFAULT CHARACTER SET WIN1251;

CREATE TABLE GROUPS (

ID_G INTEGER NOT NULL,

NAZV VARCHAR(4),

GOD INTEGER,

CHISL INTEGER

);

CREATE TABLE PREDM (

ID_P INTEGER NOT NULL,

NAZV VARCHAR(25)

);

CREATE TABLE ZAN (

ID_Z INTEGER NOT NULL,

ID_UP INTEGER,

D DATE,

T TIME,

VID_Z CHAR(1),

H SMALLINT DEFAULT 2

);

CREATE TABLE UP (

ID_UP INTEGER NOT NULL,

ID_G INTEGER,

ID_P INTEGER,

SEM INTEGER,

H_L INTEGER,

H_P INTEGER,

H_L_CALC COMPUTED BY ((select sum(H) from zan where zan.id_up=up.id_up and vid_z='Л')),

H_P_CALC COMPUTED BY ((select sum(H) from zan where zan.id_up=up.id_up and vid_z='П'))

);

CREATE TABLE PREPODS (

ID_P INTEGER NOT NULL,

FIO VARCHAR(30),

DR DATE

);

/* Check constraints definition */

ALTER TABLE ZAN ADD CHECK (VID_Z IN ('Л', 'П'));

ALTER TABLE UP ADD CONSTRAINT UNQ1_UP UNIQUE (ID_G, ID_P, SEM);

ALTER TABLE GROUPS ADD CONSTRAINT PK_GROUPS PRIMARY KEY (ID_G);

ALTER TABLE PREDM ADD CONSTRAINT PK_PREDM PRIMARY KEY (ID_P);

ALTER TABLE UP ADD CONSTRAINT PK_UP PRIMARY KEY (ID_UP);

ALTER TABLE ZAN ADD CONSTRAINT PK_ZAN PRIMARY KEY (ID_Z);

ALTER TABLE UP ADD CONSTRAINT FK_UP_1 FOREIGN KEY (ID_G) REFERENCES GROUPS (ID_G) ON UPDATE CASCADE;

ALTER TABLE UP ADD CONSTRAINT FK_UP_2 FOREIGN KEY (ID_P) REFERENCES PREDM (ID_P) ON UPDATE CASCADE;

ALTER TABLE ZAN ADD CONSTRAINT FK_ZAN_1 FOREIGN KEY (ID_UP) REFERENCES UP (ID_UP) ON UPDATE CASCADE;

ALTER PROCEDURE ADD_ZAN (ID_Z INTEGER, N INTEGER) AS

declare variable d date;

declare variable t time;

declare variable vid_z char(1);

declare variable h smallint;

declare variable id_up integer;

begin

select id_up, d, t, vid_z, h from zan where id_z =:id_z

into:id_up,:d,:t,:vid_z,:h;

while (n>0) do

begin

d = d+7;

insert into zan (id_up, d, t, vid_z, h)

values (:id_up,:d,:t,:vid_z,:h);

n=n-1;

end

end

Выбор средств реализации

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

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

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

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

В данной курсовой работе в качестве СУБД выступает сервер баз данных Firebird. Firebird является клоном такого известного продукта фирмы Borland, как Interbase. InterBase – сервер баз данных, имеющий 20-летнюю историю (создан в 1985 году). Инновации, предложенные в этом сервере, не только остаются актуальными до сих пор, но и начинают широко внедряться в альтернативных СУБД. Основной особенностью функциональности InterBase является версионность.

Механизм версионности кроме InterBase практически нигде не использовался, и потихоньку начал внедряться в коммерческих серверах не более 10 лет назад. На текущий момент в той или иной степени версионный механизм поддерживают кроме InterBase и Firebird: Oracle, PostgreSQL, а также MS SQL 2005. В 2000 году компания Borland в силу специфических причин выпустила InterBase 6.0 в OpenSource. Когда исходные коды InterBase были опубликованы, группа пользователей скопировала исходные тексты и начала новый проект под названием Firebird. Далее, с версии InterBase 6.5 Borland вернулся к схеме платного сервера с закрытыми исходными текстами, а Firebird продолжил существование как бесплатный для частного и коммерческого использования сервер с открытыми исходными текстами.