Курсовая работа по базе данных

То есть одному номеру читателя в таблице «Читатели» будет соответствовать несколько записей в таблице «Книги».

Закрываем окно «Схема данных.

Проектирование физической структуры базы данных

После завершения построения логической модели БД, перейдем непосредственно к созданию физической модели БД.

На локальном сервере (MS Server 2019) создаем новую БД с названием library (Рисунок 19).

Рисунок 19 – Создание БД library

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

2 Построение ER — модели

Подсистема вывода предприятия ООО «Садовая техника» осуществляет:

· вывод справочника и информации о газонокосилках;

· вывод справочника и информации о клиентах;

· вывод справочника и информации о комплектации техники;

· вывод справочника и информации о совершенных продажах;

Подсистема обработки предприятия ООО «Садовая техника» осуществляет функции обработки данных, таких как:

· выборка данных во всех таблицах;

· редактирование данных во всех таблицах;

· сортировка данных по товару, комплектации, клиенту, дате;

· добавление данных во все таблицы;

· удаление данных из всех таблиц.

Нормализация отношений предметной области

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

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

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

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

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

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

Все исходные таблицы находятся в 1NF и 2 NF, так же все таблицы, кроме таблицы Товары, находятся так же в 3 NF.

Таблица Товары не находится в 3 NF, так как размер наценки на товар зависит от Типа товара. Таким образом, таблица Товары должна быть разделена на две: Товары (Наименование товара, Код типа); Типы товаров (Наименование типа товара, Процент наценки).

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

Перечислим итоговые отношения:

Продавцы (Код продавца, ФИО продавца, Должность);

Товары (Код товара, Наименование товара, Тип);

Склад (Код склада, Наименование склада, Адрес, Профиль);

Секция торгового зала (Номер секции, Название секции, ФИО заведующего);

Типы товаров (Код типа, Наименование типа, Процент наценки);

Товары на складе (Код склада, Код товара, Цена, Количество);

Поставки (Номер поставки, Код склада, Код секции, Код товара, Количество, Дата поставки);

Товары в зале (Код товара, Номер секции, Количество);

Продажи (Номер чека, Код товара, Дата продажи, Количество, Код продавца).

2 Проектирование ER-модели в реляционную модель

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

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

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

3. Первичный ключ сущности становится первичным ключом соответствующего отношения.

4. В каждое отношение, соответствующее подчиненной сущности добавляется набор атрибутов основной сущности, являющийся первичным ключом основной сущности. В отношении, соответствующим подчиненной сущности этот набор атрибутов становится внешним ключом.

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

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

7. При другом варианте для каждого подтипа и для супертипа создаются свои отдельные отношения.

Следуя этим правилам, построим в следующем разделе курсового проекта таблицы для базы данных.

Структура таблиц базы данных (в режиме конструктора)

Исходя из условия задания, необходимо создать две таблицы со следующими полями:

Постановка задачи

Спроектировать базу данных для работников управления торговли.

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

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

·         какие товары имеются в магазине (на базе);

·         какие отсутствующие товары может заказать магазин на базе;

·         какие товары и в каком количестве имеются в отделе магазина;

·         список заведующих отделом магазина;

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

·         закупка нового товара;

·         закрытие отдела в магазине;

·         изменение цены товара.

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

ПРИЛОЖЕНИЕ 2 – Логическая структура БД для домашней библиотеки.

В таблицу внесены следующие данные

Таблица читатели имеет графы:

«Номер читателя» — содержит информацию об индивидуальном номере читателя.

«ФИО читателя» — содержит фамилию, имя, отчество читателя.

Разработка структуры базы данных

Структура базы данных разрабатывается на основе концептуальной модели. На рисунке 2.8 представлена ER-диаграмма БД. В таблицах 2.1-2.7 представлено описание таблиц базы данных.

Рисунок 2.8 — ER – диаграмма БД

Таблица 2.1 — Описание полей таблицы «ГруппаКласс»

Таблица 2.2 — Описание полей таблицы «Замечание»

Таблица 2.3 — Описание полей таблицы «Решение»

Таблица 2.4 — Описание полей таблицы «Исходный код решения»

Таблица 2.5 — Описание полей таблицы «Результат»

Таблица 2.6 — Описание полей таблицы «Задание»

Таблица 2.7 — Описание полей таблицы «Пользователь»

Таблица «Книги» Имеет следующие графы

«Номер читателя», «Дата выдачи книги», «Код книги», «Жанр книги», «Название книги», «Год издания», «Издательство».

В графе «Номер читателя» содержатся данные о номере читателя, которому выдана данная книга.

В графе «Дата выдачи книги» содержится информация о дате выдачи данной книги читателю.

В графах «Код книги», «Жанр книги», «Название книги», «Год издания», «Издательства» содержится информация о книгах.

Проектирование логической структуры базы данных

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

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

Преследуя финальную цель – иметь удобную и понятную БД для домашней библиотеки – необходимо создать таблицу, в которой мы будем хранить данные о книгах – books (Рисунок 12).

Рисунок 12 – Таблица books

В качестве столбцов таблицы мы добавляем:

Теперь создаем таблицу с авторами – authors (Рисунок 13).

Рисунок 13 – Таблица authors

Таблица со списком жанров и поджанров – genres (Рисунок 14).

Рисунок 14 – Таблица genres

Таблица с перечнем языков – languages (Рисунок 15).

Рисунок 15 – Таблица languages

Таблица с цветами – colors (Рисунок 16).

Рисунок 16 – Таблица colors

Таблица с определением места книги – position (Рисунок 17).

Рисунок 17 – таблица position

Таблица со всеми шкафами и полками – storage (Рисунок 18).

Рисунок 18 – таблица storage

Полная структура БД представлена в Приложении 2.

Преобразование ER- модели в реляционную модель

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

Для преобразования связей используют правила.

В соответствии с типами отношений, представленных на ER диаграмме, будут использованы:

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

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

Перечислим отношения и укажем их первичные ключи:

Продавцы (ФИО продавца, Должность);

Склад (Наименование склада, Адрес, Профиль);

Секция торгового зала (Название секции, ФИО заведующего);

Товары (Наименование товара, Тип, Процент наценки);

Товары на складе (Наименование склада, Наименование товара, Цена, Количество) (отношение добавлено по правилу 6);

Поставки (Наименование склада, Название секции, Наименование товара, Количество, Дата поставки) (отношение добавлено по правилу 7);

Товары в зале (Наименование товара, Название секции, Количество) (отношение добавлено по правилу 5);

Продажи (Номер чека, Наименование товара, Дата продажи, Количество, ФИО продавца) (отношение добавлено по правилу 6).

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

Исследование

Вычислим результирующее значение качества кода разработанной системой. Расчеты показаны в таблице 2.8.

Таблица 2.8 – Расчет результирующей оценки

Результирующая оценка кода системы получилось равной 0,87, что является хорошим показателем, учитывая, что код системы писался на “скорую руку”. Полученное значение оценки примерно соответствует 4-ке по 5-ти бальной шкале.

Этот же код, оценённый экспертами, получил среднюю оценку 4 по 5-ти бальной шкале, что неплохо согласуется с результатами оценки кода системой.

В таблице 2.9 показаны результаты 3-х экспериментов по оценке качества кода.

Таблица 2.9 – Результаты экспериментов

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

7 Способы повышения производительности доступа к данным

Способы повышения производительности доступа к данным.

Индекс — это упорядоченный (буквенный или числовой) список столбцов или групп столбцов в таблице.

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

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

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

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

Триггер — это именованный блок PL/SQL с разделами:

2. Выполняемым разделом,

3. Разделом исключительным ситуации

Триггер выполняется неявно, Всякий раз, когда происходит событие, запускается этот триггер, акт выполнения триггера называется активизация. Запускается триггер операциями DML (insert, update, delete), выполняемых на базе данных СУБД.

Для каждой таблицы можно определить три типа триггеров:

1. три пер ввода;

2. триггер добавления;

3. триггер обновления.

Триггеры можно использовать:

1. для отслеживания модификации данных;

2. для журнализации, регистрации событий;

3. для реализации ряда комплексных организационных правил;

4. для автоматического вычисление столбцов

5. для осуществления сложных процедур защиты данных.

Список создание триггера:

Or replace — пересоздает триггер, если он уже существует,то есть можно заменять триггер без удаления или создания нового

BEFORE — инициализация триггера, перед его исполнением

AFTER — СУБД возбуждает триггер, после исполнения предложения триггера.

DELETE — СУБД возбуждает триггер, каждый раз когда предложение удаляет строку из таблицы

INSERT — СУБД возбуждает триггер, каждый раз когда в предложение вставляется новая строка

UPDATE — указывает, что СУБД возбуждает триггер каждый раз когда выполняется предложение update.

OF — изменение столбца

ON определяет имя триггера, по которому создается триггер. Можно использовать корреляционные имена в блоке PL/SQL и фраза when, чтобы обращаться конкретно к старому или новому значениям столбца текущей строки.

FOR EACH ROW — указывает что триггер представляет собой триггер строк,

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

WHEN — ограничение триггера. Содержит условие SQL, которое должно быть удовлетворено, чтобы СУБД возбудил триггер (только для триггера строк).

1. Предложение триггера. Определение предложения триггера указывает, какие предложение SQL будут заставлять СУБД возбуждать этот триггер.

2. Ограничение триггера. When — дополнительное «условие», которое должно быть удовлетворено для возбуждения строк триггера строк.

3. Действие триггера (тело). Его описывает блок PL/SQL. который СУБД исполняет при возбуждении триггера. Каждый раз, когда выдается предложение триггера, СУБД вычисляет условие ограничения триггера. Если оно удовлетворено, то СУБД возбуждает триггер, исполняя действие триггера.

Создание триггера для проектируемой базы данных:

1) Триггер создает автоинкремент для таблицы Клиенты

CREATE OR ALTER TRIGGER KLIENTY_BI FOR KLIENTY

ACTIVE BEFORE INSERT POSITION 0

if (new.kod_k is null) then

new. kod_k = gen_id(gen_klienty_id,1);

2) Так же для других таблиц.

CREATE OR ALTER TRIGGER CVET_BI FOR CVET

if (new.kod_c is null) then

new.kod_c = gen_id(gen_cvet_id,1);

CREATE OR ALTER TRIGGER KONSTRUKCIA_BI FOR KONSTRUKCIA

if (new.kod_kon is null) then

new. kod_kon= gen_id(gen_konstrukcia_id,1);

CREATE OR ALTER TRIGGER PROIZVODITEL_BI FOR PROIZVODITEL

if (new.kod_p is null) then

new. kod_p= gen_id(gen_proizvoditel_id,1);

Триггер отслеживает изменения в таблице СОТРУДНИК и записывает их в таблицу СОТРУДНИК_ЖУРНАЛ.

Сначала создадим новую таблицу, аналогичную исходной, но с добавлением дополнительного столбца, где будет отражаться тип выполненой операции (insert, update, delete).

CREATE TABLE KLIENTY_GURNAL (

ID_FIO VARCHAR2 (30),

ADRES VARCHAR2 (30),

create or replace trigger sotr_trigger

before insert or delete or update on KLIENTY for each row

rw2 varchar2 (30);

rw4 varchar2 (30);

if inserting then

insert into KLIENTY _GURNAL values(rw1,rw2,rw3,rw4,rw5,rw6);

elsif deleting then

elsif updating then

6 Формирование простых и сложных запросов к базе данных

SELЕСТ — дает пользователю возможность получить информацию из базы данных.

FROM — ключевое слово, которое указывает источник запрашиваемой информации. Если используется несколько таблиц, то они перечисляются через запятую после FROM.

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

Если необходим поиск, удовлетворяющий нескольким требованиям, то используют:

1. Логические операции: AND — обе операции истины, OR — хотя бы одна истина, NOT — поиск по критерию, который не должен быть выполнен.

При необходимости в выборе информации из нескольких таблиц, для размещения нескольких запросов и объединения их вывода используют UNION.

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

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

В любой ситуации, где применяется реляционный оператор равенства (=), можно использовать IN.

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

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

Создание запросов для проектируемой базы данных:

1. Показать все данные таблицы «Производитель».

select * from PROIZVODITEL

2. Показать все цвета в таблице «Цвет».

select cvet from cvet

3. Показать фамилию, телефон, адрес и паспортные данные клиента в таблице «Клиенты».

select id_fio, telefon, adres, pasport from klienty

4. Показать модель газонокосилки, год выпуска которой 2014

select model from gazonokosilki where god_vipuska=’2014′

5. Вывести фамилию, номер телефона, адрес и паспортные данные клиента, чья фамилия начинается на букву «В».

select id_fio, telefon, adres, pasport from klienty where id_fio like ‘В%’

6. Отсортировать клиентов по убыванию

select * from klienty order BY id_fio DESC

7. Вывести все газонокосилки, которые работают на электричестве.

select kod_G, PROIZVODITEL, MODEL, GOD_VIPUSKA, CVET, KONSTRUKCIA, tip_dvigatela, CENA from ((((GAZONOKOSILKI inner join PROIZVODITEL on gazonokosilki.id_proizvoditel =proizvoditel.kod_P) inner join cvet on gazonokosilki.ID_cvet =CVET.kod_c) inner join konstrukcia on gazonokosilki.id_konstrukcia=konstrukcia.kod_kon) inner join tip_dvigatela on gazonokosilki.id_tip_dvigatela=tip_dvigatela.kod_td) where tip_dvigatela=(select tip_dvigatela from tip_dvigatela where tip_dvigatela=’Электрический’)

8. Вывести всю отсортированную по возрастанию информацию по дате из таблицы «Газонокосилки».

select kod_G, PROIZVODITEL, MODEL, GOD_VIPUSKA, CVET, KONSTRUKCIA, tip_dvigatela, CENA from ((((GAZONOKOSILKI inner join PROIZVODITEL on gazonokosilki.id_proizvoditel = proizvoditel.kod_P) inner join cvet on gazonokosilki.ID_cvet = CVET.kod_c) inner join konstrukcia on gazonokosilki.id_konstrukcia = konstrukcia.kod_kon) inner join tip_dvigatela on gazonokosilki.id_tip_dvigatela = tip_dvigatela.kod_td) ORDER BY god_vipuska ASC

9. Вывести имя клиента и наименование товара купленного по максимальной цене за все время.

select model, id_FIO, CENA from ((JURNAL_PRODAJ inner join gazonokosilki on JURNAL_PRODAJ.name_tovara = gazonokosilki.kod_g) inner join klienty on jurnal_prodaj.fio=klienty.kod_k) where cena=(select max(cena) from gazonokosilki)

10. Вывести информацию о газонокосилках, цена которых ниже 5000.

select kod_G, PROIZVODITEL, MODEL, GOD_VIPUSKA, CVET, KONSTRUKCIA, tip_dvigatela, CENA from ((((GAZONOKOSILKI inner join PROIZVODITEL on gazonokosilki.id_proizvoditel =proizvoditel.kod_P) inner join cvet on gazonokosilki.ID_cvet =CVET.kod_c) inner join konstrukcia on gazonokosilki.id_konstrukcia=konstrukcia.kod_kon) inner join tip_dvigatela on gazonokosilki.id_tip_dvigatela=tip_dvigatela.kod_td) where cena<5000

11. Вывести товар, цена которого выше 5000 и год выпуска не больше чем 2013 год.

1 Подсистема хранения

Учитывая тот факт, что база данных по предприятию разрабатывается с точки зрения руководителя и, проанализировав предметную область предприятия ООО «Садовая техника», были определены и созданы следующие сущности базы данных.

· Сущность Газонокосилки — содержит информацию о техники на продажу.

· Сущность Клиент — содержит информацию о заказчиках, с которыми сотрудничает предприятие;

· Сущность Журнал продаж — содержит информацию о заказах, которые выполняет предприятие;

· Сущность Цвет — содержит информацию о возможных цветовых решениях техники;

· Сущность Конструкция — содержит перечень возможных конструкций техники.

· Сущность Тип двигателя — содержит перечень возможных двигателей техники.

· Сущность Производитель — содержит наименования всех доступных производителей и поставщиков техники для организации.

После определения атрибутов необходимо определить первичные (РК) и внешние ключи (FK):

1. Сущность Клиент — № Клиента (РК);

2. Сущность Газонокосилка — № Газонокосилки (РК);

3. Сущность Заказ — № Заказа (РК),

4. Сущность Цвет — № Цвета (РК).

5. Сущность Конструкция — № Конструкции (РК).

6. Сущность Производитель — № Производителя (РК).

7. Сущность Тип двигателя — № Двигателя (РК).

проектирование ER — модели в реляционную происходит разбиение связи многие-ко-многим:

Сущность Заказ Клиент — содержит информацию о заказе, который произвел клиент;

После проектирование ER-модели в реляционную необходимо провести процесс нормализации и денормализации:

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

Сущности все соответствуют 1НФ, так как имеют первичные ключи и не имеют повторяющихся групп.

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

Сущности все соответствуют 2НФ, так как представлены в 1НФ и имеют простой первичный ключ.

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

Сущности все соответствуют ЗНФ, так как представлены во 2НФ и между не ключевыми атрибутами нет взаимосвязей.

Нормализация: 4НФ (НФ Бойса — Кодда)

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

Сущности все соответствуют 4НФ, так как представлены в ЗНФ и ни первичный ключ, ни какая-либо его часть не зависят от не ключевого атрибута.

* Проводить процесс денормализации не следует, так как для этого не существует веских причин.

Для базы данных ООО «Садовая техника» были реализованы таблицы, представления, индексы, триггеры, курсоры, процедуры, выполнено заполнение таблиц.

Выбор технологии для создания интерфейса

Платформа .NET Framework предлагает две основные технологии для создания оконного интерфейса:

В результате анализа возможностей этих технологий была выбрана технология WPF.

В основе WPF лежит векторная система отрисовки, не зависящая от разрешения и созданная с расчетом на возможности современного графического оборудования. WPF расширяет базовую систему полным набором функций разработки приложений, в том числе Язык XAML (Extensible Application Markup Language), элементами управления, привязкой данных, макетом, двухмерный- и трехмерный-графикой, анимацией, стилями, шаблонами, документами, мультимедиа, текстом и оформлением. WPF входит в состав Microsoft .NET Framework и позволяет создавать приложения, включающие другие элементы библиотеки классов .NET Framework.

Декомпозиция проектируемой системы

Проектируемая система ООО «Садовая техника» состоит из следующих подсистем:

Рис. 1 Структура проектируемой системы ООО «Садовая техника»

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

Проектируемая система ООО «Садовая техника» должна содержать подсистему ввода, которая включает:

1. модуль приветствия;

2. модуль идентификации;

3. модуль авторизации;

4. модуль главного меню.

Подсистема хранения данных — это непосредственно сама БД под управлением Oracle 10g Express Edition (Oracle Database XE).

Подсистема вывода — это система, которая отображает всю базу данных или часть ее в табличной, диаграммной или картографической форме. Подсистема вывода ООО «Садовая техника» содержит:

· справочник клиентов;

· список комплектующих

· справочник техники;

· операции покупок;

19 апреля 2006 г. Страница 1 из 1

Второй отчет «Книги выданные читателям за определенный период» составлен на основе запроса «Книги выданные читателям за определенный период».

Спутниковой связи и

Справочник19Справочник по М.Связь1978

Таблица запроса имеет следующие графы

«Дата выдачи книги», «Номер читателя», «ФИО читателя», «Код книги», «Название книги», «Жанр книги», «Год издания».

Курсовая работа

По дисциплине: Информатика

Алгоритм функционирования ИС

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

Алгоритм проверки заданий представлен на рисунке 2.9.

Рисунок 2.9 – Алгоритм проверки заданий

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

8 Процедуры и функции

Процедуры — это блок PL/SQL, в состав которого входят:

Раздел исключительных ситуаций.

1. Создается с помощью команды;

3. Сохраняется в компилированном виде в базе данных. С компилированный код можно в последствии выполнить из любого блока PL SQL.

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

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

Внутри процедуры все действия выполняются над формальными параметрами. Формальные параметры выступают в роли вместилища фактических параметров.

Формальные параметры бывают трех видов:

1N — значение фактического параметра, передается в процедуру при ее вызове, внутри процедуры формируются параметры и могут быть использованы только для чтения, они не могут быть изменены. При завершении работы процедуры фактические параметры не изменяются.

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

IN OUT — значение фактических параметров передается в процедуру при ее вызове. Внутри процедуры формальные параметры могут быть считаны и в него могут быть записаны значения. Когда процедура завершается, содержимое формальных параметров присваивается к фактическим параметрам. Если вид не указан, то по умолчанию устанавливается IN.

Функция — это блок PL/SQL, в состав которого входят:

1. Раздел объявлений;

2. Выполняемый раздел;

3. Раздел исключительных ситуаций.

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

Синтаксис создания функции:

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

1) Процедура для проектируемой бд:

Процедура NEWTOVAR вставляет строку в таблицу TOVARS.

CREATE OR REPLACE PROCEDURA NEW_PRODAJA (

KOD_JP IN JURNAL_PRODAJ. KOD_JP%TYPE,

NAME_TOVARA IN JURNAL_PRODAJ.NAME_TOVARA %TYPE,

FIO IN JURNAL_PRODAJ. FIO %TYPE,

D_CENA IN JURNAL_PRODAJ.D_CENA %TYPE,

INSERT INTO JURNAL_PRODAJ (KOD_JP, NAME_TOVARA, FIO, D_CENA)

VALUES (KOD_JP, NAME_TOVARA, FIO, D_CENA)

Также ставим галочку в строке «Отображать номер на первой странице».

Кварцевым

Справочник20Справочник по Москва «Наука»1980

Справочник22Интегральные Радио и Связь1983

Количество книг всего:5

При запуске отчета появляется окно «Введите значение параметра» с надписью «Введите жанр книги», в которое необходимо ввести данные о жанре требуемых книг, например справочник, и нажать кнопку «ОК».

В результате получим следующий отчет:

Книги заданного жанра

Жанр книги:Код книги:Название книги:Издательство:Год издания:

Справочник18Справочник по М.Радио и Связь1983

Проектирование системы

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

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

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

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

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

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

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

1. объединения отношений (UNION);

2. пересечения отношений (INTERSECT);

3. взятия разности отношений (MINUS);

4. декартово произведение (TIMES).

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

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

1. моделирование данных;

2. особенности архитектуры и функциональные возможности;

3. контроль работы системы;

4. особенности разработки приложений;

7. требования к рабочей среде;

8. смешанные критерии.

2 Этапы физической реализации проектируемой базы данных

Реализация — это этап превращения концептуальной модели в функционирующую базу данных. Реализация включает этапы:

1. Выбор и приобретение СУБД.

2. Преобразование концептуальной модели в физическую модель.

3. Построение словаря.

4. Заполнение базы данных.

5. Создание прикладных программ.

6. Обучение пользователей.

Размещено на Allbest

9 Курсоры

Курсор должен быть объявлен и описан, до того как на него будет произведена ссылка. В нем можно использовать любые операторы select, в том числе соединение, объединение, вычитание. Все переменные, которые используются в курсоре должны быть ему видимы, то есть они должны быть объявлены до их использования в курсоре.

При открытии курсора:

1. Анализируются значения переменных привязки;

2. На основе значений переменных привязки определяется активный набор, то есть набор строк, возвращаемый запросом;

3. Указатель активного набора установлен на первую строку. Чтобы переменные, привязки присвоить новые значения и курсор работал с ними, надо курсор закрыть. Присвоить новые значения переменным привязки и снова открыть курсор

Считывание строк из курсора:

Выполняется с помощью оператора FETCH.

С помощью этого считываем одну строку из курсора. Тип переменных курсора должен соответствовать переменным списка выбора запросов.

Закрытие курсора производят после того, как выбран весь активный набор, при этом все отведенные ресурсы для курсора освободятся: пространство для хранения активного набора, временное пространство, использующее для определения такого набора.

Курсорные атрибуты добавляются к имени курсора в блоке PL/SQL подобно атрибутам % type и % rowtype.

ПРИЛОЖЕНИЕ 1 – Структура тестовой БД.

Глава 1.

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

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

В качестве языка программирования для обучения был выбран язык C#. C# — это самый удобный язык.

Правила именования параметров функций:

Правила именования свойств:

Правила именования полей:

Правила именования переменных:

Для именования констант используется стиль pascal case.

Правила именования enum’ов:

Правила именования exception’ов:

В таблице 1.1 приведены сводные правила именования идентификаторов.

Таблица 1.1 — Сводная таблица правил именования идентификаторов

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

На рисунке 2.1 приводится структурная схема проектируемой ИС.

Рисунок 2.1 – Структурная схема системы