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

Министерство  образования и науки Российской Федерации 

МЕЖДУНАРОДНЫЙ ИНСТИТУТ КОМПЬЮТЕРНЫХ ТЕХНОЛОГИЙ 

Кафедра “Системы информационной безопасности” 
 
 
 
 
 
 
 
 
 
 
 

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

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

Выполнил:

Студент группы Ибо-031

Минаков А. Г. 

Проверил:

к.т.н. доц. 

Батищев Р.В. 
 
 
 
 
 
 
 
 
 
 

Воронеж 2006

 

      Содержание 

Задание кафедры………………………………………………………………………………..…….3

Описание  предметной области……………………………………………………………………..4

Диаграмма «сущность-связь»……………………………………………………………………....8

Нормализованные таблицы в 3 нормальной форме………………………………………………9

Описание  основных функций программы ………………………………………………………10

Текст программы…………………………………………………………………………………..13

Выводы по работе…………………………………………………………………………………20

Список  использованной литературы……………………………………………………………..21

 

      Задание кафедры 

     Написать  программу на языке СУБД, реализующей элементы языка SQL. Даны сущности, между которыми необходимо установить связь. Атрибуты сущностей задаются самостоятельно (3-6 на каждую сущность). При необходимости, добавление новых сущностей приветствуется. Программа должна иметь удобный интерфейс пользователя и корректно реализовывать основные операции (добавление, удаление, изменение, поиск записи по любому атрибуту, сортировку при выводе).

     Вариант № 7: Бухгалтерия предприятия. Сущности: поставщик, поставка, товар.

 

      Описание предметной области 

     Для начала разберемся с понятиями.

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

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

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

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

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

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

     Рассмотрим, например, такую таблицу: 

     № паспорта Фамилия Имя Отчество Должность 

     123456 Иванов Иван Иванович Директор 

     234567 Петров Петр Иванович Его зам 

     345678 Сидорова Мария Ивановна Секретарша  

     В данной таблице в качестве потенциального ключа можно рассматривать любой столбец.

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

     Первичные ключи. Итак, с потенциальными ключами определились. Первичный ключ - это один из потенциальных ключей. Тот, который больше понравится. В реальной ситуации, новичок выберет номер паспорта. А что выберет профессионал? Профессионал добавит еще одно поле-счетчик, которое будет содержать уникальное для каждой записи значение. В Delphi такой тип поля называется AutoIncrement, в SQL Server есть целых 2 варианта - TimeStamp и свойтсво Identity поля.

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

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

     Код работника Вид движения Сумма 

     1   Оклад   100 

     1   Премия  30 

     1   Налоги  -25 

     2   Оклад   90 

     ... ... ... 

     Код работника Фимилия Имя Отчество 

     1   Иванов Иван Иванович 

     2   Петров Петр Иванович 

     3   Сидорова Мария Ивановна  

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

     Ссылочной целостностью, по-английски Refential Integriyr, называется такое состояние, когда у нас все что надо правильно находится. Контроль ссылочной целостности - обеспечение такого состояния.

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

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

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

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

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

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

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

     Неделимость означает, что ваше поле не должно делиться на более мелкие. Например, речь идет о базе сотрудников для отдела кадров. Будет ли поле "Фамилия" неделимым? Ясно, что будет, куда его еще делить. А поле "ФИО"? Тут все зависит от контекста - если не предполагаеся использовать потом экзотические запросы типа "Выбрать всех Александровичей", то тоже можно считать его неделимым. А вот адрес лучше разделить на улицу, дом и квартиру, т.е. на 2 или 3 поля, тогда будет проще выбрать всех живущих на одной улице. Хотя, можете и его считать неделимым, если адрес - второстепенная информация. А вот с телефоном его объединять не стоит.

     Неповторяемость означает, что не повторяется значение полей от одного поля к другому. Имеется ввиду не та ситуация, когда указывается несколько полей с одинаковыми значениями. Например делается записная книжка. Какие поля туда внесencz? Фамилия, имя, телефон, e-mail... А может несколько телефонов? В наше время почти у каждого есть и рабочий, и домашний, и мобильный... А у некоторых может быть несколько рабочих или несколько мобильных номеров. Так сколько таких полей ввести? Правильнее всего будет создать еще одну таблицу с телефонами, а в первой только поместить ссылку на нее. Тогда можно будет для каждого указать произвольное число телефонов. 

     Код Фамилия Адрес.... 

     1 Иванов   

     2 Петров

             

     Чей Какой  Номер 

     1 Рабочий 1 23-45-67 

     1 Рабочий 2 23-45-98 

     1 Домашний 11-34-98 

     2 Домашний 45-09-87 

     ... ...  ...  

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

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

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

     Первый - если у нас накладные нумеруются каждый день начиная с первой, то номер не может однозначно определить накладную, и не может быть первичным  ключом. А номер вместе с датой - может. Можно поискать первичные ключи среди имеющихся полей (номер паспорта в базе сотрудников), а можно попытаться объединить несколько, пытаясь обеспечить уникальность.

     Очень простой вариант - создаем поле-счетчик  и указываем его в качестве первичного ключа.