Разработка базы данных для хранения информации о мероприятиях и продуктах

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ГБОУ ВПО МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ

Задание на курсовую работу по дисциплине «Базы данных»

Вариант №6

Постановка задачи

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

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

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

Проверочные вопросы

- Как отсортировать несколько столбцов?

- Как используется оператор having с оператором group by?

Напишите и выполните следующие запросы

1. Отображение всех столбцов и строк

2. Использование списка столбцов

3. Сортировка с помощью оператора ORDER BY

4. Сортировка с несколькими столбцами

5. Выбор строк с помощью оператора WHERE

6. Выбор строк с помощью оператора WHERE с текстовыми значениями

7. Использование оператора LIKE

8. Используйте сложные условия WHERE

9. Примените функцию Sum

10. Примените функцию Count(*)

11. Использование оператора WHERE с функциями обобщения

12. Использование оператора DISTINCT

13. Группировка и функции обобщения

14. Ограничение количества групп с помощью оператора HAVING

15. Использование в одном запросе операторов HAVING и WHERE

16. Объединение данных из нескольких таблиц

17. Объединение операций слияния с другими условиями оператора WHERE

18. Объединения более двух таблиц

19. Использование подзапросов

Рекомендуемая литература

Карпова Т.С. Базы данных; модели, разработка, реализация. - СПб.: Питер.

Хомоненко А.Д. и др. Базы данных. - М .: КОРОНА.

Фаронов В.В. Программирование баз данных в Delphi 7. - СПб.: Питер.

Курсовая работа должна быть сдана на проверку до !!!

Домашнюю работу принял к исполнению / /

(подпись) (Расшифровка подписи)

Содержание

Введение

1. Основные понятия базы данных

1.1 База данных

1.2 Реляционная БД

2. Основные этапы проектирования

2.1 Концептуальная (логическая) модель БД "Экспресс поставки"

2.2 Физическая модель БД "Экспресс поставки"

3. Создание БД в Access

4. SQL запросы к БД

Заключение

Список литературы и используемых источников

Введение

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

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

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

1. Основные понятия базы данных

1.1 База данных

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

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

Структурирование - это введение соглашений о способах представления данных.

Неструктурированными называют данные, записанные, например, в текстовом файле.

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

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

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

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

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

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

Классификация баз данных.

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

Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК.

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

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

Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:

· файл-сервер;

· клиент-сервер.

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

Рисунок 1 - Схема обработки информации в БД по принципу файл-сервер

Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL. Концепция клиент-сервер условно изображена на рис. 2.

Рисунок 2 - Схема обработки информации в БД по принципу клиент-сервер

Структурные элементы баз данных.

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

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

- имя, например. Фамилия, Имя, Отчество, Дата рождения:

- тип, например, символьный, числовой, календарный;

- длин, например, 15 байт, причем будет определяться максимально возможным количеством символов;

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

Запись - совокупность логически связанных полей. Экземпляр записи - отдельная реализация записи, содержащая конкретные значения ее полей. Файл (таблица) - совокупность экземпляров записей одной структуры

Описание логической структуры записи файла содержит последовательность расположения полей записи и их основные характеристики.

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

1.2 Реляционная модель данных

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации на рис. 3:

Рисунок 3 - Реляционная модель отношения Сотрудники

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

2. Основные этапы проектирования

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Логическое (даталогическое) проектирование -- создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель -- набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.

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

Связь между этапами проектирования показана на рис.4:

Рисунок 4 - Основные этапы проектирования

2.1 Создание концептуальной модели базы данных. Концептуальная модель БД «Экспресс поставки»

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

Основными компонентами концептуальной модели являются:

* Данные, циркулирующие в данной предметной области;

* Описание классов, объектов предметной области и связей между ними;

* Описание информационных потребностей пользователей.

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

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

Этапы концептуального проектирования:

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

Охват предметной области данного предприятия.

2. Определение типов сущностей.

Определение основных типов сущностей, которые требуются для конкретного представления.

3. Определение типов связей.

Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе.

4. Определение атрибутов и связывание их с типами сущностей и связей.

Связывание атрибутов с соответствующими типами сущностей или связей.

5. Определение доменов атрибутов.

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

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

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

7. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).

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

8. Проверка модели на отсутствие избыточности.

Проверка на отсутствие какой-либо избыточности данных в модели.

9. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

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

10. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

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

Концептуальная модель БД «Экспресс поставки» представлена на рис 5:

Рисунок 5 - Концептуальная модель

2.2 Создание физической модели. Физическая модель данных БД «Экспресс поставки»

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

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

Физическая модель данных должна соответствовать требованиям, предъявляемым к проектируемой системе;

Выбор определенной физической модели должен быть аргументирован;

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

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

Erwin поддерживает автоматическую генерацию физической модели данных для конкретной СУБД. При этом логическая модель трансформируется в физическую по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключи становятся индексами (таблица 1).

Таблица 1 - Сопоставление компонентов логической и физической модели

Логическая модель	Физическая модель
Сущность	Таблица
Атрибут	Столбец
Логический тип	Физический тип
Первичный ключ	Первичный ключ, индекс PK
Внешний ключ	Внешний ключ, индекс FK
Альтернативный ключ	Индекс AK
Правило бизнес - логики	Триггер или сохраненная процедура
Взаимосвязи	Взаимосвязи, определяемые FK атрибутами

В полученной модели еще необходимо скорректировать типы и размеры полей ( таблица 2):

Таблица 2 - Типы данных объектов на примере «Экспресс поставки»

Таблица	Атрибут	Тип данных
Клиент	E-mail	Text (25)
	Признак	Text (5)
	ФИО/Название	Text (65)
	Телефон	Integer
	Адрес	Text (20)
Мероприятие	Id_m	counter
	Стоимость	Currency
	Адрес	Text (20)
	Дата	Date/Time
	Кол-во прорций	Number
Товар	Id_t	counter
	Название	Text (20)
	Стоимость	Currency
Рецепт	Id_r	counter
	Вес	Number
	Способ пригот.	Memo
Ингридиенты	Id_i	counter
	Название	Text (25)
	Стоимость	Currency

Физическая модель БД «Экспресс поставки» представлена на рис. 6:



Рисунок 6 - Физическая модель

3. Создание БД в Access

Для создания БД я буду использовать программу Microsoft Access (СУБД Access).

Работа с пакетом Access требует выполнения двух основных этапов:

-создание базы данных

-использование базы данных для обработки информации

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

1. полное "ручное" описание структуры базы данных как набора таблиц, записей и полей

2. на основе имеющихся заготовок-шаблонов баз данных (всего их 22), из которых можно выбрать необходимые таблицы и поля

Описание каждой таблицы включает в себя:

1. задание имени таблицы

2. определение ключевого поля (обычно это поле счетчика-кода), которое задается на первом месте в списке полей

3. перечисление всех остальных входящих в таблицу полей с указанием их имен и типов (не забыть поля - внешние ключи!)

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

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

Анализируя задание курсовой работы, можно выделить 5 таблиц: «клиент», «мероприятие», «товар», «рецепт», «ингредиенты».

В таблицу «клиент» входят поля:

- E-mail (ключевое поле)

- Признак

- ФИО/Название

- Телефон

- Адрес

В поле «признак» добавим условие - «част.» ИЛИ «корп.». Это поле делит клиентов на частные и корпоративные.

Рисунок 7 - Конструктор табл. «клиент»

В таблицу «мероприятие» входят поля:

- id_m (ключевое поле)

- E-mail$Клиент

- Стоимость

- Адрес

- Дата

- Кол-во порций

В таблицу «Товар» входят:

- id_t (ключевое поле)

- Название

-Стоимость

- id_m$мероприятие

В таблицу «Рецепт» входят:

- id_r (ключевое поле)

- id_t$товар

- Вес

- Способ приготовления

И наконец, в таблицу «ингредиенты» входит:

-id_i (ключевое поле)

-Название

- Стоимость

- id_r$рецепт

Теперь нужно составить схему и связать таблицы используя связи вида: 1:М (один- ко- многим) и 1:1 ( один- к- одному).



Рисунок 8 - Схема данных в Access «Экспресс поставки

База данных почти готова. Осталось ввести информацию.

Здесь мы видим как работает БД «Экспресс поставки» и построенные связи.

4. SQL Запросы БД

1 Отображение всех столбцов и строк

SELECT *

FROM клиент, мероприятие, товар, рецепт, ингредиенты;

Результат:

2 Использование списка столбцов

SELECT клиент.Признак, клиент.Телефон

FROM клиент;

Результат :

3 Сортировка с помощью оператора ORDER BY

SELECT клиент.Признак, клиент.Телефон, клиент.[ФИО/Название]

FROM клиент

ORDER BY клиент.[ФИО/Название];

Результат:

4 Сортировка с несколькими столбцами

SELECT клиент.Признак, клиент.Телефон, клиент.[ФИО/Название]

FROM клиент

ORDER BY клиент.[ФИО/Название], клиент.Телефон;

Результат:

5 Выбор строк с помощью оператора WHERE SELECT мероприятие.Стоимость, мероприятие.[Кол-во порций]

FROM мероприятие

WHERE (((мероприятие.[Кол-во порций]) >5));

Результат:

6 Выбор строк с помощью оператора WHERE с текстовыми значениями

SELECT клиент.Признак, клиент.Телефон, клиент.[ФИО/Название]

FROM клиент WHERE (((клиент.Признак) = "част.")); Результат :



7 Использование оператора LIKE

SELECT клиент.Признак, клиент.Телефон, клиент.[ФИО/Название]

FROM клиент WHERE (((клиент.Телефон) Like "67*"));

Результат:

8 Используйте сложные условия WHERE

SELECT мероприятие.Стоимость, мероприятие.[Кол-во порций], мероприятие.Адрес

FROM мероприятие

WHERE мероприятие.[Кол-во порций] >5 And мероприятие.[Кол-во порций] <2000;

Результат:

9 Примените функцию Sum

SELECT Sum (мероприятие.Стоимость) As [Summa]

FROM мероприятие;

Результат:

10 Примените функцию Count(*)

SELECT Count(*) As [Всего строк]

FROM мероприятие;

Результат:

11 Использование оператора WHERE с функциями обобщения

SELECT Sum (мероприятие.Стоимость) As [Summa]

FROM мероприятие

WHERE (((мероприятие.[Кол-во порций]) >5));

Результат:

12 Использование оператора DISTINCT

SELECT DISTINCT клиент.Признак

FROM клиент;

Результат:

13 Группировка и функции обобщения

SELECT DISTINCT товар.Название, Avg(товар.Стоимость) AS [Avg_стоимость]

FROM товар

GROUP BY товар.Название;

Результат:

14 Ограничение количества групп с помощью оператора HAVING

SELECT DISTINCT товар.Название, Avg(товар.Стоимость) AS [Avg_стоимость]

FROM товар

GROUP BY товар.Название

HAVING Avg(товар.Стоимость) >1000;

Результат:

15 Использование в одном запросе операторов HAVING и WHERE

SELECT DISTINCT товар.Название, Avg(товар.Стоимость) AS [Avg_стоимость]

FROM товар

WHERE (((товар.Стоимость) Like "5*"))

GROUP BY товар.Название

HAVING Avg(товар.Стоимость) >1000;

Результат:

16 Объединение данных из нескольких таблиц

SELECT мероприятие.[id_m], клиент.[E-mail], клиент.Признак

FROM клиент INNER JOIN [мероприятие] ON клиент.[E-mail]=мероприятие.[E-mail$клиент];

Результат:



17 Объединение операций слияния с другими условиями оператора WHERE

SELECT мероприятие.[id_m], клиент.[E-mail], клиент.Признак

FROM клиент INNER JOIN [мероприятие] ON клиент.[E-mail]=мероприятие.[E-mail$клиент]

WHERE (((клиент.Признак) = "част."));

Результат :

18 Объединения более двух таблиц

SELECT мероприятие.[id_m], клиент.[E-mail], клиент.Признак, товар.Название, товар.Стоимость

FROM товар INNER JOIN ([клиент] INNER JOIN мероприятие ON клиент.[E-mail]=мероприятие.[E-mail$клиент]) ON мероприятие.[id_m]=товар.[id_m$мероприятие] ;

Результат:



19 Использование подзапросов

SELECT мероприятие.Стоимость, мероприятие.[Кол-во порций]

FROM мероприятие

WHERE (((мероприятие.[Кол-во порций]) > (SELECT avg (мероприятие.[Кол-во порций]) FROM мероприятие)))

Результат:

Заключение

субд реляционный sql access

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

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

Список литературы и используемых источников

1. Дунаев В.В.-Базы данных. Язык SQL-БХВ-Петербург (2009)

2. Хомоненко А.Д. Цыганков В.М. Мальцев М.Г. -Базы данных-КОРОНА(2004)

3. http://ru.wikipedia.org

4. http://itteach.ru/

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