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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Работа № 93832


Наименование:


Курсовик Объектно-ориентированные системы управления базами данных

Информация:

Тип работы: Курсовик. Добавлен: 12.01.2016. Сдан: 2010. Страниц: 43. Уникальность по antiplagiat.ru: < 30%

Описание (план):



стр.
Введение……………………………………………………………………. 3
1. Реляционные базы данных ……………………………………………... 4
1.1 Объектно-реляционные методы. ……………………………..……. 8
2. Спорные моменты технологии объектно-ориентированных СУБД..... 12
3. Недостатки модели ООБД……………………………………………… 16
3.1. Отсутствие интероперабельности между РБД и ООБД…………. 17
3.2. Недостаточность средств для оптимизации запросов…………… 17
3.3. Отсутствие стандартной алгебры запросов………………………. 19
3.4. Отсутствие средств обеспечения запросов………………………. 20
3.5. Отсутствие поддержки представлений…………………………… 20
3.6. Проблемы с безопасностью……………………………………….. 21
3.7. Отсутствие поддержки динамических изменений определений классов……………………………………………………………………… 21
3.8. Ограниченная поддержка ограничений целостности……………. 21
3.9. Ограниченные возможности настройки производительности….. 22
3.10. Недостаточная поддержка сложных объектов…………………. 22
3.11. Ограниченная интеграция с объектно-ориентированными системами программирования…………………………………………….. 22
3.12. Ограниченный выигрыш в производительности……………….. 23
4. Поставщики ООСУБД…………………………………………………... 23
5. Унификация реляционной и объектно-ориентированной технологий. 25
5.1. Архитектуры унификации………………………………………… 26
5.2. Унификация моделей данных…………………………………….. 29
6. Мифы, связанные с ООБД……………………………………………… 32
6.1. ООБД в 10 (в 1000) раз быстрее, чем РБД……………………….. 32
6.2. ООБД устраняют необходимость в языке программирования…. 34
6.3. ООБД устраняют необходимость в соединениях………………... 35
6.4. ООБД устраняют необходимость в ключах……………………… 35
6.5. В ООБД не может быть непроцедурного языка запросов………. 35
6.6. Обработка запросов будет нарушать инкапсуляцию……………. 36
6.7. ООБД могут поддерживать версии и длинные транзакции…….. 37
6.8. ООБД могут поддерживать данные мультимедиа……………… 38
6.9. ООБД не имеют теоретического основания……………………... 38
7. Реляционные БД и ООБД………………………………………………. 40
Заключение ………………………………………………………………… 42
Список использованной литературы ……………………………………. 43


Введение
Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х. Однако наиболее активно это направление развивается в последние годы. Возникновение направления ООБД определяется прежде всего потребностя-ми практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной. Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программ-мирования с абстрактными типами данных и объектно-ориентированных языков программирования. Среди языков и систем программирования наибольшее первичное влияние на ООБД оказал Smalltalk. Этот язык сам по себе не является полностью пионерским, хотя в нем была введена новая терминология, являющаяся теперь наиболее распространенной в объектно-ориентированном программировании. На самом деле, Smalltalk основан на ряде ранее выдвинутых концепций. Мы не будем подробно останавливаться на языке Smalltalk, просто попробуем провести анализ реляционных и объектно-ориентированных баз данных, попробуем выделить их плюсы и минусы, преимущества и недостатки.


1. Реляционные базы данных
В процессе эволюции информационных систем и технологий в конце XX века, человечеству появилась потребность создавать электронные информационные базы данных, без которых наше сегодняшнее существование мы просто, порой, даже не можем себе представить. В пример можно поставить даже примитивный телефонный справочник, который до электронной версии представлял собой толстую книгу и весьма нелегкую. Однако, сейчас воспользовавшись средствами массовой коммуникации, а именно сетью Интернет, можно с легкостью раздобыть электронный телефонный справочник, и найти номер необходимого абонента, вместо перелистывания «толстого талмуда», нажав всего пару-тройку кнопок на клавиатуре персонального компьютера. В середине ХХ века когда начались только появляться машины, соразмерные с двухэтажным домом, по операциям вряд ли превосходившими стандартный калькулятор, обслуживали несколько десятков человек. С каждым днём развитие компьютерного Мира совершенствовалось от языка машин до уровня пользователя. И на сегодняшний день мы уже имеем достаточную базу для решения фактически любой задачи. С помощью персонального компьютера можно заниматься проектированием зданий, коммуникаций, вести бухгалтерскую отчетность, общаться с другими людьми и много другого.
Остановимся по подробнее на баз данных. Базы данных представляют собой такой набор информации, при выборе из которой конкретных значений, пользователь получает необходимый результат для дальнейшей работы. Вся информация, содержащаяся в базе данных, имеет какие-либо свойства, т.е. имеет поля. Проще говоря, поле базы данных - это критерий существования данных в базе. Вернемся к нашему примеру - телефонному справочнику, в нем содержится информация по фамилии, имени, отчеству, номеру телефона и адресу абонента, т. е. можно выделить три поля: Ф.И.О., телефон и адрес. Каждый абонент имеющий ф.и.о., адрес и номер телефона попадает в телефонный справочник. Такой набор данных является записью в
базе данных. Уникальным в каждой записи будет номер телефона, ведь по сути не может же быть двух одинаковых номеров. А могут ли быть одинаковые ф.и.о. или адрес? Да, а почему бы и нет, в нашей стране много и Ивановых, и Петровых и Сидоровых, а в одном доме может жить и два Петровых и три Сидоровых. А что если создать таблицы с фамилиями, именами, отчествами, адресами домов:

Таблица с фамилиями (Т1) Таблица с адресами (Т4)
1. Иванов 1. ул. Ленина, д. 2
2. Петров 2. пр-т Мира, д.44
3. Сидоров 3. пр-д Швейников, д. 21

Таблица с именами (Т2)
1. Илья
2. Павел
3. Роман

Таблица с отчествами (Т3)
1. Юрьевич
2. Викторович
3. Николаевич
Итак мы получили 4 таблицы с исходными данными. а теперь попробуем сделать таблицу с номерами телефонов и данными абонентов:
№ Фамилия Имя Отчество Номер Адрес
1 Иванов Павел Николаевич 532551 ул. Ленина, д. 2
2 Сидоров Илья Юрьевич 521144 пр-д Швейников д. 21
3 Сидоров Роман Викторович 511254 пр-т Мира, д.44
Используя таблицы с фамилиями, именами и отчествами можно преобразить эту таблицу с данными абонентов, в другую, используя сделанные ранее, таблицы с адресами, фамилиями, именами и отчествами:
№ Фамилия Имя Отчество Номер Адрес
1 1ая запись из Т1 2ая запись из Т2 3я запись из Т3 532551 1ая запись из Т4
2 3я запись из Т1 1ая запись из Т2 2ая запись из Т3 521144 3ая запись из Т4
3 3я запись из Т1 3я запись из Т2 3ая запись из Т3 511254 2ая запись из Т4
Или просто можем указать номер той записи, которой соответствует те или иные фамилия, имя, отчество и адрес, потому что из названия колонок можно понять из какой именно таблицы, стоит брать данные:
№ФамилияИмяОтчествоНомерАдрес
1 1 2 3 532551 1
2 3 1 2 521144 3
3 3 3 3 511254 2
Таким образом, мы и пришли к такому примеру, который и является реляционной базой данных. Реляционная база данных представляется пользователю как совокупность таблиц и ничего кроме таблиц. В реляционных базах данных все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. Строки таблицы составлены из полей, заранее известных базе данных. В
большинстве систем нельзя добавлять новые типы данных. Каждая строка в
таблице соответствует одной записи. Положение данной строки может
изменяться вместе с удалением или вставкой новых строк.
Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. В примере с телефонным справочником можно выделить номер телефона как первичный ключ. Если одна таблица содержит первичный ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key). Т. е. в нашем телефонном справочнике в таблицах Т1, Т2, Т3, Т4 есть первичные ключи - номера по порядку, а для основной таблицы, содержащей номера телефонов, эти ключи являются внешними.
Так как все поля одной таблицы должны содержать постоянное число полей
заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных.
Реляционные базы данных ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации - Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных Систем Управления Базами Данных (СУБД).
Первые разработки систем управления реляционными базами данных (реляционных СУБД) были выполнены в компании IBM в начале 1970х годов. Тогда же был создан язык данных, предназначенный для работы в этих системах. Экспериментальная версия этого языка называлась SEEQUEL - от англ. Structured English QUEry Language (структурированный язык запросов). Однако официальная версия была названа короче - SQL (Structured Query Langгage). Точнее говоря, SQL - это подъязык данных, поскольку СУБД содержит и другие языковые средства. В 1981г. IBM выпускает реляционную СУБД SQL/DS. К этому же времени компания Relation Software Inc. (сегодня это Oracle Corporation) уже выпустила свою реляционную СУБД. Эти продукты сразу же стали стандартами систем, предназначенных для управления базами данных. В состав этих продуктов вошел и SQL, который фактически стал стандартом для подъязыков данных. производители других СУБД выпустили свои версии SQL. В них имелись не только основные возможности продуктов IBM. Чтобы получить некоторое преимущество для «своей» СУБД, производители вводили некоторые расширения SQL. Вместе с тем, начались работы по созданию общепризнанного стандарта SQL. SQL задумывался как простой язык запросов к реляционной базе данных, близкий к естественному (точнее, к английскому) языку. Предполагалось, что близость по форме к естественному языку сделает SQL средством, доступным для широкого применения обычными пользователями баз данных, а не только программистами. Первоначально SQL не содержал никаких управляющих структур, свойственных обычным языкам программирования. Запросы, синтаксис которых довольно прост, вводились прямо с консоли последовательно один за другим и в этой же последовательности выполнялись. Однако SQL так и не стал инструментом банковских служащих, продавцов авиа и ж/д билетов, экономистов и других служащих различных фирм и организаций, использующих информацию, хранимую в базах данных. Для них простой язык SQL оказался слишком сложным и неудобным, несмотря на свою близость к естественному языку. На практике с базой данных обычно работают посредством приложений, написанных программистами на процедурных языках, например на С, Visual Basic, Pascal, Java и др. Часто приложения создаются в специальных средах разработки, таких как Delphi, Microsoft Access, Visual dBase и др. При этом разработчику приложения практически не приходится писать коды приложения, поскольку он использует компоненты среды разработки, и по факту, получается, что за него делает всё среда разработки. Во всяком случае, работа с программными кодами оказывается минимальной. Эти приложения имеют графический, дружелюбный интерфейс, не вынуждающий пользователя непосредственно вводить запросы на языке SQL. Вместо него это делает приложение.
Реляционные базы данных могут и действительно существуют вне зависимости от приложений, обеспечивающих пользовательский интерфейс. Если по каким-то причинам такого интерфейса нет, то доступ к базе данных можно осуществить с помощью SQL, используя какое-нибудь приложение, с помощью которого можно соединится с базой данных, ввести и отправить SQL-запрос (например, IBExpert).

1. 1. Объектно-реляционные методы.
Реляционных баз данных обладают рядом достоинств:
1) разделение таблиц разными программами;
2) развернутый «код возврата» при ошибках;
3) высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);
4) относительно высокая скорость при работе с большими объемами данных.
Кроме того, во всем мире значительные средства уже инвестированы в
реляционные СУБД. Многие организации не уверены, что затраты, связанные с переходом на объектные базы данных, окупятся.
Поэтому многие пользователи заинтересованы в комбинированном подходе,
который бы им позволил воспользоваться достоинствами объектных баз данных, не отказываясь полностью от своих реляционных БД. Такие решения
действительно существуют. Если переход от реляционной базы к объектной
обходится слишком дорого, то применение последней в качестве расширения и дополнения реляционных СУБД часто является более экономичной альтернативой.
Объектно-реляционные адаптеры. Этот метод предполагает использование так называемого объектно-реляционного адаптера, который автоматически выделяет программные объекты и сохраняет их в реляционных базах данных. Объектно-ориентированные приложение работает как рядовой пользователь СУБД. Несмотря на некоторое снижение производительности, такой вариант позволяет программистам целиком сконцентрироваться на объектно-ориентированной разработке. Кроме того, все имеющиеся на предприятии приложения по-прежнему могут обращаться к данным, хранящимся в реляционной форме. Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например в качестве связующего ПО, объединяющего объектно-ориентированные приложения с реляционными СУБД.
Объектно-реляционные шлюзы. При использовании такого метода
пользователь взаимодействует с БД п........

Список используемой литературы

1. А. С. Марков, К. Ю. Лисовский, Базы данных. Введение в теорию и методологию
Издательство: Финансы и статистика, 2006 г.
2. А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев, Базы данных, Бином-Пресс, 2007 г.
3. Д. Кренке, Теория и практика построения баз данных, Питер, 2005 г.
4. К. Дж. Дейт, Введение в системы баз данных, Вильямс, 2001
5. С. С. Магазов, Лекции и практические занятия по технологии баз данных, КомКнига, 2006 г.
6. Ю. А. Шпак, Проектирование баз данных. Просто как дважды два, Эксмо, 2007 г.
7. Интернет.


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть похожие работы

* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.