19

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

Содержание

Введение

1. Теоретическая информация по БД

1.1 Описание структуры БД

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

1.3 ER-диаграмма

2. Запросы к БД

3. Функциональная схема приложения

Заключение

Введение

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

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

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

1. Теоретическая информация по БД

База данных (БД, database) - поименованная совокупность структурированных данных, относящихся к определенной предметной области.

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

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

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

Таблица базы данных (table) - регулярная структура, которая состоит из однотипных строк (записей, records), разбитых на столбцы (поля, fields).

В теории реляционных баз данных синоним таблицы - отношение (relation), в котором строка называется кортежем, а столбец называется атрибутом.

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

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

Первичный ключ (primary key) - главный ключевой элемент, однозначно идентифицирующий строку в таблице. Могут также существовать альтернативный (candidate key) и уникальный (unique key) ключи, служащие также для идентификации строк в таблице.

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

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

Связь (relation) - функциональная зависимость между объектами. В реляционных базах данных между таблицами устанавливаются связи по ключам, один из которых в главной (parent, родительской) таблице - первичный, второй - внешний ключ - во внешней (child, дочерней) таблице, как правило, первичным не является и образует связь "один ко многим" (1:N). В случае первичного внешнего ключа связь между таблицами имеет тип "один к одному" (1:1). Информация о связях сохраняется в базе данных.

Внешний ключ (foreign key) - ключевой элемент подчиненной (внешней, дочерней) таблицы, значение которого совпадает со значением первичного ключа главной (родительской) таблицы. Ссылочная целостность данных (referential integrity) - набор правил, обеспечивающих соответствие ключевых значений в связанных таблицах. Хранимые процедуры (stored procedures) - программные модули, сохраняемые в базе данных для выполнения определенных операций с информацией базы.

Триггеры (triggers) - хранимые процедуры, обеспечивающие соблюдение условий ссылочной целостности данных в операциях изменения первичных ключей (возможно каскадное изменение данных), удалении записей в главной таблице (каскадное удаление в дочерних таблицах) и добавлении записей или изменении данных в дочерних таблицах. Объект (object) - элемент информационной системы, обладающий определенными свойствами (properties) и определенным образом реагирующий на внешние события (events).Система - совокупность взаимодействующих между собой и с внешним окружением объектов. Репликация базы данных - создание копий базы данных (реплик), которые могут обмениваться обновляемыми данными или реплицированными формами, отчетами или другими объектами в результате выполнения процесса синхронизации.

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

Язык SQL (Structured Query Language) - универсальный язык работы с базами данных, включающий возможности ее создания, модификации структуры, отбора данных по запросам, модификации информации в базе и прочие операции манипулирования базой данных.

Классификация БД и СУБД

По технологии обработки данных базы данных подразделяются на централизованные и распределенные.

Централизованная база данных хранится в памяти одной вычислительной системы. Эта вычислительная система может быть мэйнфреймом - тогда доступ к ней организуется с использованием терминалов - или файловым сервером локальной сети ПК.

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

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

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

Централизованные базы данных с сетевым доступом могут иметь следующую архитектуру:

1. файл-сервер;

2. клиент-сервер базы данных;

3. "тонкий клиент" - сервер приложений - сервер базы данных (трехуровневая архитектура).

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

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

Реляционные системы

Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы - в 1970 г. [1].

Техническая статья "Реляционная модель данных для больших разделяемых банков данных" доктора Е.Ф. Кодда, опубликованная в 1970 г., является родоначальницей современной теории реляционных БД. Доктор Кодд определил 13 правил реляционной модели (которые называют 12 правилами Кодда).

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

Некоторые команды Transact-SQL

Для выборки данных в Transact-SQL существует команда SELECT, которая позволяет как делать простую выборку всех данных из одной таблицы текущей базы данных, так и выполнять сложные запросы одновременно к множеству таблиц различных баз данных, расположенных на нескольких серверах сети В самом простейшем случае выборка данных производится с помощью команды:SELECT * FROM table_name

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

Полный синтаксис команды SELECT следующий:

SELECT select_list

[INTO new_table_] FROM table_source

[WHERE search_condition]

[GROUP BY group_by_expression]

[HAVING search_condition]

[UNION]

[ORDER BY order_expression [ASC | DESC]]

[COMPUTE compure_expression]

[FOR] [OPTION <query_hint>]



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

Для выполнения сортировки данных, возвращаемых запросом, в распоряжении пользователей имеется раздел ORDER BY, специально предназначенный для определения параметров порядка вывода строк. Синтаксис этого раздела таков:

ORDER BY {order_by_expression [ASC | DESC]} [,...n]

INSERT - Добавляет запись в таблицу.

Синтаксис команды:

INSERT [INTO]

{table_name | view_name} [(column_list)]

{DEFAULT VALUES | values_list | select_statement}

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

1.1 Описание структуры БД

База данных составлялась на основе реляционной системы. Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы - в 1970 г.

Техническая статья «Реляционная модель данных для больших разделяемых банков данных» доктора Е.Ф. Кодда, опубликованная в 1970 г., является родоначальницей современной теории реляционных БД. Доктор Кодд определил 13 правил реляционной модели (которые называют 12 правилами Кодда).

12 правил Кодда:

1. Реляционная СУБД должна быть способна полностью управлять базой данных через ее реляционные возможности.

2. Информационное правило - вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения в таблицах.

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

4. Поддержка пустых значений (null value) - СУБД должна уметь работать с пустыми значениями (неизвестными или неиспользованными значениями), в отличие от значений по умолчанию и независимо для любых доменов.

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

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

7. Правило обновления представлений (views) - все представления, теоретически обновляемые, могут быть обновлены через систему.

8. Вставка, обновление и удаление - СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление

9. Физическая независимость данных - на программы-приложения и специальные программы логически не влияют изменения физических методов доступа к данным и структур хранилищ данных.

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

11. Независимость целостности - язык БД должен быть способен определять правила целостности. Они должны сохраняться в онлайновом справочнике, и не должно существовать способа их обойти.

12. Независимость распределения - на программы-приложения и специальные программы логически не влияет, первый раз используются данные или повторно.

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

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

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

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

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

1. все данные представляются в виде упорядоченной структуры, определенной в виде строк и столбцов и называемой отношением;

2. все значения являются скалярами. Это означает, что для любой строки и столбца любого отношения существует одно и только одно значение;

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

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

· D_id - № по порядку

· D_name - № договора

· Stoimost - стоимость договора

· Obor - оборудование

· Data_zakl - дата заключения договора

· Srok_deistv - срок действия договора

Таблица dogovor_dop - дополнительная информация по договорам:

· P_name - №-ра проектов

· Zakazchik - заказчик

· Rukovoditel - руководитель договора

· Ispolnitel - исполнители договора

Таблица proekt:

· P_name - № проекта

· Stoimost - стоимость

· Data - дата исполнения проекта

Таблица proekt_dop:

· P_name - № проекта

· D_name - №-ра договоров

· Zakazchik - заказчик

· Rukovoditel - руководитель проекта

· Ispolnitel - исполнители проекта

Таблица obor:

· Otdel_id - № отдела

· Ob_name - название оборудования

· P_name - №-ра проектов

· Data - дата эксплуатации

Таблица otdel_dop:

· Otdel_id - № отдела

· Prinadlegn - принадлежность отделу

· Ispolzovanie - пользование отделом

Таблица otdel_dop:

· Otdel - название отдела

· Dolznost - должность

· Familia - фамилия

· Name - имя

· Otchestvo - отчество

· God_rozden - год рождения

· Zarplata - заработная плата

Таблица kontragenti:

· Kg_name - название организации

· Specifik - спецификация

· Adres - адрес

· Tel - телефон

· Bank_rekv - банковские реквизиты

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

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

Первая нормальная форма

1. запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию)

2. запрещает множественные столбцы (содержащие значения типа списка и т.п.)

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

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

Вторая нормальная форма

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

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

Третья нормальная форма

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

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

Нормальная форма Бойса-Кодда

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

Все таблицы базы данных представлены в нормальной форме Бойса-Кодда, так как имеется только один первичный ключ (id).

Четвертая нормальная форма

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

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

1.3 ER-диаграмма

информационный программный база данный



2. Запросы БД

Для работы с базой данных были осуществлены следующие SQL-запросы:

Для вывода информации по указанной дате или указанному интервалу времени:

Query1->SQL->Add(“SELECT * FROM dogovor, proekt WHERE (Data_zakl =” ”) AND (Srok_deistv >=” ”)”);

Query1->SQL->Add(“SELECT Stoimost FROM dogovor, proekt WHERE (Srok_deistv <” ”)”);

Query1->SQL->Add(“SELECT * FROM obor WHERE (Data =” ”)”);

Query1->SQL->Add(“SELECT * FROM otdel_dop WHERE ((Dolznost=” ”) OR (Familia=” ”) AND (Data=” ”)”);

Для вывода информации по сотрудникам проектной организации:

Query1->SQL->Add(“SELECT * FROM otdel_dop WHERE ((Dolznost=” ”) OR (God_rozden=” ”)”);

Query1->SQL->Add(“SELECT * FROM otdel_dop WHERE (Dolznost=”Руководитель ”);

Query1->SQL->Add(“SELECT * FROM proekt_dop WHERE ((Dolznost=” ”) OR (P_name=” ”)”);

Для вывода информации по договорам и проектам :

Query1->SQL->Add(“SELECT D_name, P_name FROM proekt WHERE ((P_name =” ”) OR (D_name =” ”)”);

Query1->SQL->Add(“SELECT D_name, P_name, Stoimost FROM dogovor_dop, proekt_dop WHERE (Ispolnitel =” ”);

Query1->SQL->Add(“SELECT * FROM dogovor WHERE ((Stoimost =” ”) AND (Data_zakl =” ”) (Srok_deistv =” ”)”);

Query1->SQL->Add(“SELECT * FROM proekt WHERE ((Stoimost =” ”) AND (Data =” ”)”);

Для вывода информации по оборудованию:

Query1->SQL->Add(“SELECT Oborudovanie FROM dogovor WHERE ((D_name =” ”) OR (P_name=” ”)”);

Query1->SQL->Add(“SELECT * FROM dogovor WHERE (Oborudovanie =” ”);



3. Функциональная схема приложения

19

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



Заключение

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

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

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