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

1. Общая характеристика баз данных
Базами данных (БД) называют электронные хранилища информации, доступ к которым осуществляется при помощью одного или нескольких компьютеров. База данных состоит из таблиц. Таблицы состоят из полей (столбцов) и записей (строк). Разработчик базы данных определяет структуру БД, т. е. создает поля (задает имя, определяет тип и свойства полей), а пользователь наполняет ее, т. е. вводит, изменяет или удаляет записи.
Системы Управления Базами Данных (СУБД) это программные средства, предназначенные для создания, наполнения и удаления баз данных. По назначению СУБД подразделяются на три вида: Промышленные универсального назначения, Промышленные специализированные и разрабатываемые под конкретного заказчика [1]. Универсальные рассчитаны «на все случаи жизни» и, как следствие, либо очень сложны в использовании и требуют от пользователя специальных знаний, либо просты, но ограничены в возможностях. Примером универсальных СУБД могут служить Access, FoxPro, Oracle, DB2. Специализированные направлены на выполнение узких задач и потому создаются так, чтобы они были просты в использовании для профессионалов в своей области. Примером таких СУБД могут служить различные бухгалтерские или складские программы (БЭСТ, 1С Предприятие, Правовая система Гарант). СУБД, разрабатываемые под конкретного заказчика, максимально учитывают нужды потребителя, его ситуацию и не требуют дополнительных знаний от пользователя. Но они весьма дороги и требуют времени для создания, отладки и внедрения, тогда как Универсальные и Специализированные сравнительно дешевы и вводятся в эксплуатацию за сравнительно короткий срок (от недели до месяца).
По расположению СУБД подразделяются на локальные и распределенные (удаленные). Все части локальной СУБД расположены на одном компьютере. Локальные СУБД могут работать сети, но в любом случае все ее части находятся на одном компьютере (локально). В отличие от локальных, распределенные СУБД работают только при наличии компьютерной сети и располагаются как минимум на двух компьютерах. Значительная часть программно-аппаратных средств распределенной СУБД централизована и расположена на достаточно мощном компьютере (сервере). На компьютерах пользователей расположена только небольшая часть СУБД (клиент), позволяющая связываться с главной частью. Распределенные СУБД еще называют Клиент-серверными СУБД.
В каждой таблице БД должен существовать первичный ключ одно или несколько полей, однозначно определяющие каждую запись таблицы. Значение первичного ключа должно быть уникальным, то есть в таблице не должно быть двух или более записей с одинаковым значением первичного ключа. Например, если есть таблица по накладным какого-то склада и нумерация накладных каждый месяц начинается с 1, то первичным ключом могут выступать набор из двух полей: Номер и Дата накладной. Потому как могут быть записи с одинаковым номером накладной или с одинаковой датой, но не может быть записи в которой будут одинаковы и номер, и дата.
Базы данных изменяются в рамках транзакции. Под транзакцией понимается воздействие на базу данных, переводящее ее из одного целостного состояния в другое. Воздействие выражается в изменении данных в таблицах базы. Если одно из изменений, вносимых в БД в рамках транзакции, завершается неуспешно, должен быть произведен откат к состоянию БД, имевшему место до начала транзакции. Следовательно, все изменения в рамках одной транзакции либо одновременно подтверждаются, либо не подтверждается ни одно из них.



2. Краткая история развития баз данных
До появления СУБД все данные в компьютерных системах хранились в виде отдельных файлов. Система управления файлами (СУФ), которая обычно являлась частью операционной системы, следила за именами файлов и их расположением. В системах управления файлами ничего не знали о внутреннем строении файлов данных. Эту информацию имели только программы, работавшие с этими данными. То есть каждое приложение для работы с данными содержало описание структуры данных. Такой подход приводил к тому, что даже при незначительных изменениях в структуре файла данных приходилось изменять все приложения, использовавшие этот файл. Со временем количество и объем файлов росли и на сопровождения СУФ, а также разработку новых приложений требовалось все больше и больше усилий.
Проблемы с сопровождением больших систем. основанных на файлов привели в конце 60-х к появлению созданию СУБД. Идея СУБД заключалась в изъятии определения структуры файлов данных из приложений, работающих с ними.
Первые СУБД имели иерархическую структуру (иерархические СУБД). Поскольку СУБД применялись в основном в экономике, а их применение было связано с планированием производства, то такая структура наиболее полно отвечала нуждам промышленных предприятий [2].
Такой список является по своей природе иерархическим. Для хранения данных, имеющих такую структуру были разработаны иерархическая модель данных. В такой модели для описанного случая каждая запись предсталяет собой конкретный строительный узел. Между записями существуют отношения предок/потомок, связывающие каждый конкретный узел с его составляющими.
Одной из наиболее популярных иерархических СУБД была Information Managment System (IMS) от компании IBM, появившаяся в 1986 году. Достоинствами данной СУБД явлалась простота модели данных, использование отношений предок/потомок (что позволяло делать заключения «А является частью Б» или «А принадлежит Б»), а также прекрасное быстродействие.
Если структура данных оказывалась сложнее, чем традиционная иерархия, то простота организации иерархической базы данных становилась ее недостатком. Например, если рассмотреть работу торговой компании, то один заказ может участвовать в нескольких отношениях предок/потомок: с заказчиком, с менеджером или торговой точкой, отпустившей товар, а также с самим товаром. Однако иерархия допускает наличие только одного отношения между ее записями. В связи с этим для таких приложений была разработана сетевая модель данных, допускавшая множественные отношения типа предок/потомок. Такие отношения назывались множествами. В 1971 году на конференции по языкам обработки данных (Conference on Data System Languages CODASYL) был опубликован стандарт сетевых баз данных, который известен как модель CODASYL.
С точки зрения программиста, доступ к сетевой базе данных был очень схож с доступом к иерархической базой данных. Прикладная программа могла
найти конкретную запись предка по ключу,
перейти к первому потомку в конкретном моножестве,
перейти в сторону от одного потомка к другому,
перейти вверх от потомка к его предку.
И опять программисту приходилось искать информацию в базе данных последовательно перебирая все записи, но теперь он могу указать не только направление, но и требуемое отношение.
Плюсами сетевых СУБД являлись:
Гибкость. Сетевые СУБД позволяли работать с данными, имеющими достаточно сложную структуру.
Стандартизация. Принятие стандарта CODASYL привело к облегчению создания новых приложений и переносимости данных.
Быстродействие. Не смотря на сложность модели данных, сетевые СУБД позволяли достигать быстродействия, сравнимого с быстродействием иерархическиз СУБД.
И все-таки как и иерархические СУБД, сетевые имели множество недостатков. Так изменение структуры базы данных означало перестройку всего приложения. Наборы отношений и структуру записей следовало задавать наперед. Для того чтобы получить данные, программисту необходимо было писать программу для навигации по базе данных, что моглу занять от нескольких дней до нескольких недель, а информация к тому времени могла оказаться бесполезной.
Недостатки сетевых и иерархических СУБД привели к повышению интереса к новой реляционной модели данных, описанной доктором Коддом в 1970 году. Реляционная модель была попыткой упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых находятся данные. У каждой таблицы есть определенное имя, описывающее ее содержимое (следует отметить, что грамотное именование таблиц значительно влияет на простоту восприятия базы даных разработчиками). Между таблицами существуют связи. Различают три вида связей: один-к-одному, один-ко-многим, многие-ко-многим. Именно от английского слова связь (relation) и произошло название реляционные базы данных.


3. Базовые понятия реляционной модели данных
3.1. Общая характеристика реляционной модели данных
Основы реляионной модели данных были впервые изложены в статье Е.Кодда [9] в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту [11]. Согласно Дейту, реляционная модель состоит из трех частей:
Структурной части.
Целостной части.
Манипуляционной части.
Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения.
Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей.
Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление.

1. Общая характеристика баз данных 3
2. Краткая история развития баз данных 5
3. Базовые понятия реляционной модели данных 8
3.1. Общая характеристика реляционной модели данных 8
3.3. Типы данных, используемые в реляционной модели 12
3.4. Домены 13
3.5. Отношения, атрибуты, кортежи отношения 15
Табл.1 связь между терминами 16
3.6. Свойства отношений 17
4. Целостность реляционных данных 19
4.1. Null-значения 19
4.2. Потенциальные ключи 22
4.3. Целостность сущностей 23
4.4. Внешние ключи 24
4.5. Целостность внешних ключей 26
4.6. Операции, могущие нарушить ссылочную целостность 27
4.7. Стратегии поддержания ссылочной целостности 29
5. Элементы языка SQL 34
5.1. Операторы SQL 35
5.2. Использование оператора SELECT 37
5.3. Синтаксис оператора выборки данных (SELECT) 39
5.4. Порядок выполнения оператора SELECT 48
6. Транзакции и целостность баз данных 52
6.1. Понятие транзакции 53
6.2. Ограничения целостности 56
6.3. Классификация ограничений целостности 58
6.4. Реализация ограничений целостности средствами SQL 65
7. Транзакции и восстановление данных 75
7.1. Виды восстановления данных 76
7.2. Индивидуальный откат транзакции 79
7.3. Восстановление после мягкого сбоя 80
7.4. Восстановление после жесткого сбоя 83
8. Программа Кадры 84
8.1. Структура базы данных 84
8.2. Описание работы программы 88
Список литературы 99
Приложение. 100

Список литературы
1. Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 1983. - 320 с.
2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и стати-стика, 1989. - 351 с.
3. Боуман Д, Эмерсон С., Дарновски М. Практическое руководство по SQL. - Киев: Диалектика, 1997.
4. Гилуа М.М. Множественная модель данных в информационных системах. - М.: Наука, 1992.
5. Грабер М. Введение в SQL. - М.: Лори, 1996. - 379 с.
6. Грабер М. Справочное руководство по SQL. - М.: Лори, 1997. - 291 с.
7. Дейт К. Руководство по реляционной СУБД DB2. - М.: Финансы и статистика, 1988. - 320 с.
8. Дейт К. Введение в системы баз данных //6-издание. - Киев: Диалектика, 1998. - 784 с.
9. Кодд Е.Ф. Реляционная модель данных для больших совместно используемых банков данных //СУБД. - 1995. - №1
10. Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная модель данных: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 108 с.
11. Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные формы отношений и транзакции: Учебное пособие/Изд-е Башкирского ун-та. - Уфа, 1999. - 138 с