Дипломная работа

от 20 дней
от 9999 рублей

Заказать

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

от 10 дней
от 1999 рублей

Заказать

Реферат

от 3 дней
от 699 рублей

Заказать

Контрольная работа

от 3 дней
от 99 рублей
за задачу

Заказать

Диссертация

Сроки и стоимость индивидуальные

Заказать

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

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

  • Тема: Создание и ведение базы данных для автоматизации управления в конкретной предметной области (кадровый состав предприятия).
  • Автор: Ольга
  • Тип работы: Дипломная
  • Предмет: Базы данных
  • Страниц: 148
  • Год сдачи: 2008
  • ВУЗ, город: Современная Гуманитарная Академия
  • Цена(руб.): 4000 рублей

Заказать персональную работу

Выдержка

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 с

Форма заказа

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

Тип работы *
Предмет *
Название *
Дата Сдачи *
Количество Листов*
уточните задание
Ваши Пожелания
Загрузить Файлы

загрузить еще одно дополнение
Страна
Город
Ваше имя *
Эл. Почта *
Телефон *
  

Название Тип Год сдачи Страниц Цена
Автоматизированная программная система управления работой гостиницы. Дипломная 2008 52 4000
Разработка программного обеспечения КАДРОВЫЙ УЧЕТ для комитета администрации города по финансам, налоговой и кредитной политике. Дипломная 2006 125 2000
Создание автоматизированного рабочего места менеджера отдела полиграфии Дипломная 2009 108 4000
Разработка автоматизированной системы кодровой службы компании ООО "ТК Город" (на базеAccess). Дипломная 2009 97 4000
Проектирование информационной системы для кредитного отдела автомобильного салона Дипломная 2009 76 4000
Анализ предметной области и постановка задачи Дипломная 2009 77 4000
База данных по учету товаров в магазине Дипломная 2009 108 4000
Разработка и внедрение информационной системы для мебельного салона Дипломная 2009 102 2000
курсовые, дипломные, контрольные на заказ скидки на курсовые, дипломные, контрольные на заказ

© 2010-2016, Все права защищены. Принимаем заказы по всей России.