Учебная работа. Контрольная работа: Проектирование системы управления базой данных

Учебная работа. Контрольная работа: Проектирование системы управления базой данных

ВВЕДЕНИЕ

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

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

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

1. ЗАДАНИЕ НА РАЗРАБОТКУ

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

a) Для каждой группы медикаментов нужно хранить наименование.

b) Для всякого медикамента, принадлежащего какой-нибудь группе – наименование и единицу измерения.

c) Для каждой группы рецептур нужно хранить наименование.

d) Для каждой рецептуры, принадлежащей какой-нибудь группе – наименование медикамента и в котором количестве употребляется .

e) Любой продукт изготовляется по какой-нибудь рецептуре.

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

2. Воплотить разработанную схему данных с помощью SQL (подраздел DDL — «язык определения данных»). Реализация схемы данных обязана содержать нужные ограничения целостности.

3. Составить операторы SQL (подраздел DML — «язык манипулирования данными»), производящие добавление новейшей инфы в базу данных, удаление либо изменение имеющейся инфы.

4. Составить операторы SQL, осуществляющие выбор из базы данных последующей инфы:

a) Вывести информацию о медикаменте, присутствующем в самом большом количестве рецептур.

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

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

2. анализ ПРЕДМЕТНОЙ ОБЛАСТИ

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

Таблица 1.

Суть

характеристики

Группа медикаментов

Наименование группы медикаментов.

Группа рецептур

Наименование группы рецептур.

Медикаменты

Наименование медикамента, заглавие группы медикаментов, единица измерения.

Рецептуры

Заглавие медикамента, количество использующегося медикамента, наименование продукта.

Продукт

Заглавие продукта, наименование группы рецептур.

Любой медикамент принадлежит какой-либо группе. Разумеется, одной группе может принадлежать несколько медикаментов, потому меж этими сущностями существует связь «один-ко-многим» (1:M), которую можно изобразить последующим образом:

Любой медикамент принадлежит какой-нибудь рецептуре. Другими словами, меж сущностями «медикамент» и «рецептура» существует связь «один-ко-многим» (1:M):

Продукт делается по какой-нибудь рецептуре из имеющихся медикаментов. Таковым образом, меж сущностями « группа рецептур» и «продукт» существует связь «один-ко-многим» (1:M):

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

3. РАЗРАБОТКА СХЕМЫ ДАННЫХ

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

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

Типы integer not null, varchar

not null, numeric(*,*) not null означают, что поля могут быть длинноватыми целыми числами, не содержащими NULL. Тип varchar

значит, что поля содержат строчку знаков переменной длины. Тип numeric(*,*) значит, что поля содержат масштабируемые целые числа. Тип date значит, что поля содержат календарную дату.

Поля, выделенные на схеме данных курсивом, будут являться первичными ключами (PRIMARY KEY) таблиц.

Набросок 1-Логическая схема реляционной базы данных

1) Таблица Group_receptures:

— поля ID, Name, не могут содержать NULL;

— поле ID содержит целые числа, поле Name — строчка переменной длины.

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

create table Group_receptures

(IDinteger not null,

Name varchar(40) not null,

primary key (ID)

);

2) Таблица Group_medikaments:

— поля ID, Name, не могут содержать NULL;

— поле ID содержит целые числа, поле Name — строчка переменной длины.

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

create table Group_medikaments

(IDinteger not null,

Name varchar(40) not null,

primary key (ID)

);

3) Таблица Medikamenty:

— поля ID, Name_med, Group_ID,Edinica не могут содержать NULL;

— поля ID, Group_ID содержат целые числа, поля Name и Edinica — строчки переменной длины.

С учетом перечисленных требований оператор SQL, создающий таблицу смотрится последующим образом:

create table Medikamenty

(IDinteger not null,

Name_medvarchar(40) not null,

Group_ID integer not null,

Edinicavarchar(10) not null,

primary key (ID),

foreign key (Group_ID),

references Group_medikaments

);

4) Таблица Receptures:

— поля Name_ID, Preparat_ID не могут содержать NULL;

— поля Preparat_ID, Name_ID, Kol_vo содержат целые числа.

С учетом перечисленных требований оператор SQL, создающий таблицу смотрится последующим образом:

create table Receptures

(Preparat_ID integer not null,

Name_ID integer not null,

Kol_vo integer not null,

primary key (Preparat_ID,Name_ID),

foreign key (Preparat_ID),

references Preparat,

foreign key(Name_ID),

references Medikamenty

);

5) Таблица Preparat:

— все поля таблицы не могут содержать NULL;

— поля ID, Group_ID содержат целые числа, поле Name_preparat — строчка переменной длины.

Оператор SQL, создающий таблицу Preparat :

create table Preparat

(IDinteger not null,

Group_ID integer not null,

Name_preparatvarchar(40) not null,

primary key (ID),

foreign key (Group_ID),

references Group_receptures

);

4. ВЕДЕНИЕ БАЗЫ ДАННЫХ

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

Добавление новейших записей в таблицы делается с помощью оператора INSERT, удаление имеющихся записей — оператором DELETE, изменение — оператором UPDATE. Для удобства юзера можно свести эти операторы вкупе для каждой таблицы базы данных:

1) Таблица Group_receptures:

— добавление новейшей записи

insert into Group_receptures (Name)

values(:Name);

тут и дальше для всех таблиц заместо наименования поля с двоеточием перед ним (напр. «:Name») при выполнении оператора обязано подставляться конкретное

— удаление имеющейся записи

delete from Group_receptures where ID = value;

тут и дальше для всех таблиц заместо «value» при выполнении оператора обязано подставляться конкретное

— изменение имеющейся записи

update Group_receptures set Name = “value”

where ID = value2;

тут и дальше для всех таблиц заместо «value1, 2,…,n» при выполнении оператора обязано подставляться конкретное

2) Таблица Group_medikaments:

— добавление новейшей записи

insert into Group_medikaments (Name)

values(:Name);

— удаление имеющейся записи

delete from Group_medikaments where ID = value;

— изменение имеющейся записи

update Groups_medikaments set Name = “value1”

where ID = value2;

3) Таблица Medikamenty:

— добавление новейшей записи

insert into Medikamenty (Name_med, Group_ID, Edinica)

values (:Name_med, :Group_ID, :Edinica);

— удаление имеющейся записи

delete from Medikamenty where ID = value;

— изменение имеющейся записи

update Medikamenty set Name_med= “value1”, Edinica =” value2”,

where Group_ID = value4;

4) Таблица Receptures:

— добавление новейшей записи

insert into Receptures ( Preparat_ID, Name_ID, Kol_vo )

values( :Preparat_ID, :Name_ID, :Kol_vo );

— удаление имеющейся записи

delete from Receptures where Preparat_ID = value, Name_ID = value ;

— изменение имеющейся записи

update Receptures set Kol_vo= “value1”

where Preparat_ID = value2, Name_ID = value3;

5) Таблица Preparat:

— добавление новейшей записи

insert into Preparat ( Group_ID, Name_preparat )

values ( :Group_ID, :Name_preparat);

— удаление имеющейся записи

delete from Preparat where ID = value;

— изменение имеющейся записи

update Preparat set Name_preparat =” value1”,

where Group_ID = value3;

5. ВЫБОР инфы ИЗ БАЗЫ ДАННЫХ

Для выбора инфы из базы данных употребляется оператор SELECT.

1) Вывести информацию о медикаменте, присутствующем в самом большом количестве рецептур.

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

Обратимся к таблицам: Medikamenty, Receptures. Условие отбора строк — M.ID=R.Name_ID. Отобранные строчки сортируем по M.Name_med. В подзапросе группируем по R.Name_ID. Разыскиваемые данные находятся в согласовании с условием, обозначенным в предложении HAVING.

SELECT M.Name_med, count(M.Name_med)

FROM Medikamenty AS M, Receptures AS R

WHERE M.ID=R.Name_ID

GROUP BY M.Name_med

HAVING count(R.Name_ID)>=all(select count(R.Name_ID)

FROM Receptures AS R Group by R.Name_ID);

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

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

Обратимся к таблицам: Medikamenty, Receptures, Preparat. Условие отбора строк – (M.ID=R.Name_ID and R.Preparat_ID=P.ID). Отобранные строчки сортируем по R.Preparat_ID. В подзапросе группируем по

R.Preparat_ID. Разыскиваемые данные находятся в согласовании с условием, обозначенным в предложении HAVING.

SELECT R.Preparat_ID, count(R.Name_ID)

FROM Receptures AS R, Preparat AS P, Medikamenty AS M

WHERE (R.Preparat_ID=P.ID and R.Name_ID=M.ID)

GROUP BY R.Preparat_ID

HAVING count(R.Name_ID)>=all(SELECT count(R.Name_ID)

FROM Receptures R GROUP BY R.Preparat_ID);

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

Условие отбора строк обозначено в предложении WHERE. Оператор DISTINCT исключает схожие строчки.

SELECT DISTINCT R.Preparat_ID

FROM Receptures AS R, Medikamenty AS M, Preparat AS P

WHERE (P.ID=R.Preparat_ID and M.ID=R.Name_ID and

M.Name_med=’Метамизол натрия’);

ЗАКЛЮЧЕНИЕ

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

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1 Озкарахан Э. Машинки баз данных и управление базами данных. – 1989.

2 Джеймс Р. Грофф, Пол Н. Вайнберью. SQL: полное управление. – 1998.

3 Диго С.М. Проектирование и внедрение баз данных. – 1995.

]]>