Объектно-ориентированная модель данных. Объектно-ориентированная СУБД
Структурная основа организации объектно-ориентированной базы данных. Типы и структуры данных объектной модели. Манипулирование данными, характеристика ограничений целостности. Целостность данных в объектно-ориентированной модели данных, ее поддержание.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 08.06.2016 |
| Размер файла | 117,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Федеральное агентство железнодорожного транспорта
Омский государственный университет путей сообщения
Кафедра "Автоматика и системы управления"
Реферат по теме:
"Объектно-ориентированная модель данных. Объектно-ориентированная СУБД"
по дисциплине "Базы данных"
Студент гр.24Ф Т.А. Мединская
Руководитель - доцент кафедры АиСУ
Н.А. Тихонова
Омск 2016
Оглавление
- Перечень сокращений
- Введение
- 1. Объектно-ориентированная модель данных
- Типы и структуры данных объектной модели
- Манипулирование данными в объектной модели
- Ограничения целостности в объектной модели
- 2. Объектно-ориентированная СУБД
- Целостность данных в ОО-СУБД
- Подведем некоторые итоги
- Заключение
- Глоссарий
- Библиографический список
Перечень сокращений
БД - база данных;
СУБД - система управления базами данных;
ООБД - объектно-ориентированная база данных;
ООСУБД - объектно-ориентированная система управления базами данных;
ПО - программное обеспечение;
САПР - система автоматизированного проектирования;
ООМД - объектно-ориентированная модель данных.
Введение
Возникновение направления объектно-ориентированных баз данных (ООБД) определялось, прежде всего, потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем баз данных не была вполне удовлетворительной. Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивался как предыдущими работами в области баз данных, так и давно развивающимися направлениями языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.
Что касается связи с предыдущими работами в области баз данных, то наиболее сильное влияние на работы в области ООБД оказали проработки СУБД и следующего хронологически за ними семейства БД, в которых поддерживалось управление сложными объектами. Эти работы обеспечили структурную основу организации OOБД. В данном реферате будут рассмотрены ООМД и ООСУБД.
1. Объектно-ориентированная модель данных
Рассмотрим один из подходов к построению БД - использование объектно-ориентированной модели данных (ООМД). Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.).
Объектно-ориентированная модель данных ODMG, отличается от других моделей, прежде всего, в одном принципиальном аспекте. В модели данных SQL и истинной реляционной модели данных база данных представляет собой набор именованных контейнеров данных одного родового типа: таблиц или отношений соответственно. В объектно-ориентированной модели данных база данных - это набор объектов (контейнеров данных) произвольного типа.
При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:
встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;
расширение существующего языка работы с базами данных объектно-ориентированными функциями;
создание объектно-ориентированных библиотек функций для работы с БД;
создание нового языка и новой объектно-ориентированной модели данных.
К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID - object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.
Среди недостатков ООМД следует отметить отсутствие общепринятой модели, недостаток опыта создания и эксплуатации ООБД, сложность использования и недостаточность средств защиты данных.
Теперь рассмотрим, как поддержка моделей данных реализована в реальных системах управления базами данных.
В объектно-ориентированной модели (ООМ) при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Стандартная ООМ описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.
Структура ОО БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class).
Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связанную иерархию объектов.
Типы и структуры данных объектной модели
В объектной модели данных вводятся две разновидности типов: литеральные и объектные типы. Литеральные типы данных - это обычные типы данных, принятые в традиционных языках программирования. Они подразделяются на базовые скалярные числовые типы, символьные и булевские типы (атомарные литералы), конструируемые типы записей (структур) и коллекций.
Литеральный тип записи - это традиционный определяемый пользователем структурный тип, подобный структурному типу языка C или типу записи языка Pascal. Отличие состоит лишь в том, что в объектной модели атрибут типа записи может определяться не только на литеральном, но и на объектном типе, т.е. значение литерального типа записи может в качестве компонентов включать объекты. На первый взгляд это звучит странно и страшновато, но здесь все странности проистекают из особенностей объектно-ориентированной терминологии. У любого существующего объекта имеется одно и только одно местоположение, характеризующееся его идентификатором (OID). Когда в модели говорится, что некоторое структурное значение в качестве компонента имеет некоторый объект, то, конечно, имеется в виду OID этого объекта, являющийся всего лишь аналогом указательного значения в традиционных языках программирования.
Имеются четыре вида типов коллекций: типы множеств, мультимножеств (неупорядоченные наборы элементов, возможно, содержащие дубликаты), списков (упорядоченные наборы элементов, возможно, содержащие дубликаты) и словарей (множества пар <ключ, значение>, причем все ключи в этих парах должны быть различными). Типом элемента любой коллекции может являться любой скалярный или объектный тип за исключением того же типа коллекции.
Объектные типы в объектной модели данных по смыслу ближе всего к понятию класса в объектно-ориентированных языках программирования. У каждого объектного типа имеется операция создания и инициализации нового объекта этого типа. Эта операция возвращает значение OID нового объекта, который можно хранить в любом месте, где допускается хранение объектов данного типа, и использовать для обращения к операциям объекта, определенным в его объектном типе.
Имеются два вида объектных типов. Первый из них называется атомарным объектным типом. Нестрого говоря, при определении атомарного объектного типа указывается его внутренняя структура (набор свойств - атрибутов и связей) и набор операций, которые можно применять к объектам этого типа. Для определения атомарного объектного типа можно использовать механизм наследования, расширяя набор свойств и/или переопределяя существующие и добавляя новые операции.
Атрибутами называются свойства объекта, значение которых можно получить по OID объекта. Значениями атрибутов могут быть и литералы, и объекты (т.е. OID), но только тогда, когда не требуется обратная ссылка. Связи - это инверсные свойства. В этом случае значением свойства может быть только объект. Связи определяются между атомарными объектными типами. В объектной модели ODMG поддерживаются только бинарные связи, т.е. связи между двумя типами. Связи могут быть разновидностей "один-к-одному", "один-ко-многим" и "многие-ко-многим" в зависимости от того, сколько экземпляров соответствующего объектного типа может участвовать в связи.
Связи явно определяются путем указания путей обхода. Пути обхода указываются парами, по одному пути для каждого направления обхода связи. Например, в базе данных СЛУЖАЩИЕ-ОТДЕЛЫ служащий работает (works) в одном отделе, а отдел состоит (consists of) из множества служащих. Тогда путь обходаconsists_of должен быть определен в объектном типе ОТДЕЛ, а путь обхода works - в типе СЛУЖАЩИЙ. Тот факт, что пути обхода относятся к одной связи, указывается в разделе inverse обоих объявлений пути обхода. Это связь "один-ко-многим". Путь обхода consists_of ассоциирует объект типа ОТДЕЛ с литеральным множеством объектов типа СЛУЖАЩИЙ, а путь обхода works ассоциирует объект типа СЛУЖАЩИЙ с объектом типа ОТДЕЛ. Пути обхода, ведущие к коллекциям объектов, могут быть упорядоченными или неупорядоченными в зависимости от вида коллекции, указанного в объявлении пути обхода.
Заметим, что хотя связь является модельным понятием, другие понятия модели наталкивают на мысль, что единственным способом реализации связей является хранение в объекте OID или коллекции OID связанных объектов в зависимости от вида связи. Это можно сделать и с использованием должным образом типизированных атрибутов. Однако явное определение связи обеспечивает системе дополнительную информацию, которая используется в объектной модели как ограничение целостности (см. ниже).
Второй вид - это объектные типы коллекций. Как и в случае использования литеральных типов коллекций, можно определять объектные типы множеств, мультимножеств, списков и словарей. Типом элемента объектного типа коллекции может быть любой литеральный или объектный тип за исключением того же типа коллекции. У объектных типов коллекций имеются предопределенные наборы операций. В отличие от литеральных типов коллекций, которые, как и все литеральные типы являются множествами значений, объектные типы коллекций обладают операцией создания объекта, имеющего, как и все объекты, собственный OID.
Интересен и важен один специальный случай неявного использования объектов типа множества. При определении атомарного объектного типа можно в качестве одного из дополнительных свойств этого типа указать, что для него должен быть создан объект типа множества, элементами которого являются объекты данного атомарного типа (экстент объектного структурного типа). Поскольку такой объект создается неявно, его OID неизвестен, но зато у него имеется имя, явно задающееся в определении и совпадающее с именем атомарного объектного типа. Наличие этой возможности позволяет создавать объектные базы данных, состоящие из именованных контейнеров однотипных объектов, причем в действительности эти контейнеры содержат OID'ы соответствующих объектов.
Манипулирование данными в объектной модели
В стандарте ODMG в качестве базового средства манипулирования объектными базами данных предлагается язык OQL (Object Query Language). Это небольшой, но достаточно сложный язык запросов. Разработчики в целом характеризуют его следующим образом:
· OQL опирается на объектную модель ODMG (имеется в виду, что в нем поддерживаются средства доступа ко всем возможным структурам данных, допускаемых в структурной части модели).
· OQL очень близок к SQL/92. Расширения относятся к объектно-ориентированным понятиям, таким как сложные объекты, объектные идентификаторы, путевые выражения, полиморфизм, вызов операций и отложенное связывание.
· В OQL обеспечиваются высокоуровневые примитивы для работы с множествами объектов, но, кроме того, имеются настолько же эффективные примитивы для работы со структурами, списками и массивами.
· OQL является функциональным языком, допускающим неограниченную композицию операций, если операнды не выходят за пределы системы типов. Это является следствием того факта, что результат любого запроса обладает типом, принадлежащим к модели типов ODMG, и поэтому к результату запроса может быть применен новый запрос.
· OQL не является вычислительно полным языком. Он представляет собой простой язык запросов.
· Операторы языка OQL могут вызываться из любого языка программирования, для которого в стандарте ODMG определены правила связывания. И, наоборот, в запросах OQL могут присутствовать вызовы операций, запрограммированных на этих языках.
· В OQL не определяются явные операции обновления, а используются вызовы операций, определенных в объектах для целей обновления.
· В OQL обеспечивается декларативный доступ к объектам. По этой причине OQL-запросы могут хорошо оптимизироваться.
· Можно легко определить формальную семантику OQL.
Характерный пример языка OQL.
Получить номера руководителей отделов и тех служащих их отделов, зарплата которых превышает 20000 руб.
SELECT DISTINCT STRUCT (ОТД_РУК: D. ОТД_РУК, СЛУ: (SELECT E FROM D. CONSISTS_OF AS E WHERE E. СЛУ_ЗАРП > 20000.00)) FROM ОТДЕЛЫ D
Здесь предполагается, что для атомарного объектного типа ОТДЕЛ определен экстент типа множества с именем ОТДЕЛЫ. В запросе перебираются все существующие объекты типа ОТДЕЛ, и для каждого такого объекта происходит переход по связи к литеральному множеству объектов типа СЛУЖАЩИЙ, соответствующих служащим, которые работают в данном отделе. На основе этого множества формируется "усеченное" множество объектов типа СЛУЖАЩИЙ, в котором остаются только объекты-служащие с зарплатой, большей 20000.00. Результатом запроса является литеральное значение-множество, элементами которого являются значения-структуры с двумя литеральными значениями, первое из которых есть атомарное литеральное значение типа INTEGER, а второе - литеральное значение-множество с элементами-объектами типа СЛУЖАЩИЙ. Более точно, результат запроса имеет тип set < struct { integer ОТД_РУК; bag < СЛУЖАЩИЙ > СЛУ } >.
В совокупности результатом допустимых в OQL выражений запросов могут являться:
· коллекция объектов;
· индивидуальный объект;
· коллекция литеральных значений;
· индивидуальное литеральное значение.
Ограничения целостности в объектной модели
В соответствии с общей идеологией объектно-ориентированного подхода в модели ODMG два объекта считаются совпадающими в том и только в том случае, когда являются одним и тем же объектом, т.е. имеют один и тот же OID. Объекты одного объектного типа с разными OID считаются разными, даже если обладают полностью совпадающими состояниями. Поэтому в объектной модели отсутствует аналог ограничения целостности сущности реляционной модели данных. Интересно, что при определении атомарного объектного типа можно объявить ключ - набор свойств объектного класса, однозначно идентифицирующий состояние каждого объекта, входящего в экстент этого класса. Для класса может быть объявлено несколько ключей, а может не быть объявлено ни одного ключа даже при наличии определения экстента. Но при этом определение ключа не трактуется в модели как ограничение целостности; утверждается, что объявление ключа способствует повышению эффективности выполнения запросов.
Что же касается ссылочной целостности, то она поддерживается, если между двумя атомарными объектными типами определяется связь вида "один-ко-многим".
В этом случае объекты на стороне связи "один" рассматриваются как предки, а объекты на стороне связи "многие" - как потомки, и ООСУБД обязана следить за тем, чтобы не образовывались потомки без предков.
Пример логической структуры ОО БД библиотечного дела приведен на рис. 1.1.
Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА.
Различные объекты типа КНИГА, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.
Рис. 1.1 Логическая структура базы данных библиотечного дела
Логическая структура ОО БД внешне похожа на структуру иерархической БД. Основное отличие между ними состоит в методах манипулирования данными. Для выполнения действий над данными в ООМ БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма. Ограниченно могут применяться операции, подобные командам SQL (например, для создания БД).
Для выполнения действий над данными в рассматриваемой модели БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа Каталог добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов Абонент и Каталог. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.
Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга, являющимся потомками объекта типа Каталог, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свой ств вс еми дочерними объектами Абонент, Книга и Выдач а. Не случайно, поэтому значения свойства билет классов Абонент и Выдача, показанных на рис.2.9, являются одинаковыми - 00015.
Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента.
Применительно к рассматриваемому примеру полиморфизм означает, что объекты класса Книга, имеющие разных родителей из класса Каталог, могут иметь разный набор свойств.
Следовательно, программы работы с объектами класса Книга могут содержать полиморфный код.
Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД.
Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.
Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.
К объектно-ориентированным СУБД относятся POET, Jasmine, Versant, O 2, ODB - Jupiter, Iris, Orion, Postgres.
2. Объектно-ориентированная СУБД
Объектно-ориентированная (объектная) СУБД - система управления базами данных, основанная на объектной модели данных. Эта система управления обрабатывает данные как абстрактные объекты, наделённые свойствами и использующие методы взаимодействия с другими объектами окружающего мира.
Термин "объект" в программной индустрии впервые был введен в языке Simula (1967 г.) и означал какой-либо аспект моделируемой реальности. Сейчас под объектом понимается "нечто, имеющее четко определенные границы" (определение известного американского специалиста Г. Буча). Объекты, обладающие одинаковыми свойствами, составляют классы (например, курица, пингвин и чайка - объекты класса "птицы"). Обычно класс описывается как новый тип данных, а объекты (экземпляры класса) - определенные на его основе переменных.
Появление объектно-ориентированных СУБД вызвано потребностями программистов на ОО-языках, которым были необходимы средства для хранения объектов, не помещавшихся в оперативной памяти компьютера. Также важна была задача сохранения состояния объектов между повторными запусками прикладной программы. Поэтому, большинство ООСУБД представляют собой библиотеку, процедуры управления данными которой включаются в прикладную программу. Примеры реализации ООСУБД как выделеного сервера базы данных крайне редки.
В качестве примера рассмотрим объектно-ориентированную СУБД ObjectStore, которая обеспечивает долговременное хранение в базе данных объектов, созданных программами на языках С++ и Java. Вся работа с объектами ведется обычными средствами включающего ОО-языка. При этом СУБД как бы расширяет виртуальную память операционной системы. Происходит это следующим образом. Когда прикладная программа обращается к объекту, то ищет его по адресу в оперативной памяти. Нужная страница оперативной памяти может быть вытеснена в виртуальную память (область хранения неиспользуемых страниц оперативной памяти на диске). Если объекта с таким адресом в виртуальной памяти не существует, то операционная система генерирует ошибку. СУБД эту ошибку перехватывает и извлекает объект из базы данных.
ObjectStore поддерживает транзакции (в данный момент времени может существовать только одна транзакция), допускает методы доступа: хеш-таблица для несортированных данных и B-дерево для сортированных, также возможно использование SQL.
Целостность данных в ОО-СУБД
Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:
автоматическое поддержание отношений наследования
возможность объявить некоторые поля данных и методы объекта как "скрытые", не видимые для других объектов; такие поля и методы используются только методами самого объекта
создание процедур контроля целостности внутри объекта
Подведем некоторые итоги
В объектно-ориентированных базах данных, в отличие от реляционных, хранятся не записи, а объекты. ОО-подход представляет более совершенные средства для отображения реального мира, чем реляционная модель:
естественное представление данных. В реляционной модели все отношения принадлежат одному уровню, именно это осложняет преобразование иерархических связей модели "сущность-связь" в реляционную модель. ОО-модель можно рассматривать послойно, на разных уровнях абстракции.
имеется возможность определения новых типов данных и операций с ними.
В то же время, ОО-модели присущ и ряд недостатков:
отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста.
вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.
Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).
объектная ориентированная база модель
Заключение
В данной работе была рассмотрена система управления базами данных как составная часть автоматизированного банка данных. Рассмотрены СУБД, ООМД, особенности языка OQL в базах данных. Рассмотрев преимущества и недостатки разных СУБД, можно придти к выводу, что СУБД подходит для использования в крупных предприятиях и организациях, что и подтверждается статистикой.
Глоссарий
БД - информационная модель, позволяющая упорядоченно хранить данные о группе объектов, обладающих одинаковым набором свойств.
СУБД - система управления базами данных. Совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
Инкапсуляция - свойство языка программирования, позволяющее объединить и защитить данные и код в объект и скрыть реализацию объекта от пользователя (прикладного программиста). При этом пользователю предоставляется только спецификация (интерфейс) объекта.
Полиморфизм - способность функции обрабатывать данные разных типов
Наследование - метод построения концептуальной модели
Модель данных - способ структурирования дан - ных, которые рассматриваются как некоторая абстракция в отрыве от предметной области.
Библиографический список
1. Кузин А.В., Левонисова С.В. Базы данных. - М.: "Академия", 2012. - 317 с. - ISBN 978-5-7695-9308-6.
2. Кузнецов С.Д. Базы данных. - М.: "Академия", 2012. - С.496. - ISBN 978-5-7695-8430-5.
3. Рейтинг популярности СУБД за 2015 год. [Электронный ресурс]. - Режимдоступа: https: // www.opennet.ru/opennews/art. shtml? num=43645
4. Современные СУБД: оптимум и идеал. [Электронный ресурс]. - Режимдоступа: http://www.cnews.ru/reviews/rynok_bi_v_rossii_2013/articles/sovremennye_subd_optimum_i_ideal/
5. СУБД: проблема выбора. [Электронный ресурс]. - Режимдоступа: http://www.osp.ru/os/2015/01/13045322/
6. Анонс MySQL 5.6 [Электронный ресурс]. - Режимдоступа: https: // habrahabr.ru/post/168441/
7. MicrosoftMyQLServer. [Электронный ресурс]. - Режимдоступа: https: // ru. wikipedia.org/wiki/Microsoft_SQL_Server
Размещено на Allbest.ru
...Подобные документы
Сущность и функциональные особенности баз данных, их классификация и типы, внутренняя структура и элементы. Модели данных, хранящихся в базах: иерархическая, сетевая, реляционная, многомерная, объектно-ориентированная. Виды запросов и типы таблиц.
дипломная работа [66,7 K], добавлен 06.01.2014Компоненты и классификация банков данных. Модели данных: иерархическая, сетевая, реляционная, постреляционная, многомерная, объектно-ориентированная. Настольные системы управления базами данных: VisualdBase, Рarаdох, Microsoft FoxРrо и Visual FoxРrо.
курсовая работа [849,8 K], добавлен 25.04.2015Описание предметной области и обоснование актуальности разработки базы данных "Учет фонда библиотеки для Харьковского колледжа текстиля и дизайна". Построение реляционной модели данных. Типы сущностей и связей. Разработка объектно-ориентированной модели.
курсовая работа [1,1 M], добавлен 24.01.2016Общая характеристика моделей баз данных: объектно-ориентированная, иерархическая, реляционная. Всемирная паутина глобальной компьютерной сети Интернет как сетевая база данных, рассмотрение особенностей основных составляющих: узел, уровень, связь.
презентация [1,4 M], добавлен 14.10.2013Новые тенденции развития СУБД и областей их применения. Структурные элементы базы данных. Объектно-ориентированная модель программных компонентов. Формы, модули и метод разработки "Two-Way Tools". Масштабируемые средства для построения баз данных.
дипломная работа [589,5 K], добавлен 16.12.20131С: Предприятие как специализированная объектно-ориентированная система управления базами данных, ее назначение и использования в организациях, среда разработки и порядок работы с информационной базой. Объектно-ориентированные методы программирования.
методичка [47,3 K], добавлен 06.07.2009Методика разработки объектно-ориентированной модели информационной подсистемы необходимой для учета успеваемости студентов факультета, которая спроектирована с помощью программного продукта Rational Rose 2003 и унифицированного языка моделирования UML.
курсовая работа [183,9 K], добавлен 25.06.2011Анализ реляционных баз данных и способов манипулирования ими. Основные понятия баз данных, архитектура СУБД, модели данных. Модель сущность-связь, характеристика связей, классификация сущностей, структура первичных и внешних ключей, целостности данных.
курсовая работа [166,6 K], добавлен 18.07.2012Краткая характеристика предметной области. Актуальность разработки объектно-ориентированной модели информационной системы для учебной библиотеки. Создание диаграммы вариантов использования, последовательности, кооперативной диаграммы, диаграммы классов.
курсовая работа [381,8 K], добавлен 01.06.2009Разработка объектно-ориентированной модели животного, которая объясняется построением модели игры Terrarium. Модель построена на базе концепций объектно-ориентированного программирования. Разработка компонента, моделирующего поведение животного.
курсовая работа [23,2 K], добавлен 30.11.2008Сущность и характеристика типов моделей данных: иерархическая, сетевая и реляционная. Базовые понятия реляционной модели данных. Атрибуты, схема отношения базы данных. Условия целостности данных. Связи между таблицами. Общие представления о модели данных.
курсовая работа [36,1 K], добавлен 29.01.2011Основные типичные системы управления базами данных. Способы описания взаимодействий между объектами и атрибутами. Структурная и управляющая части иерархической модели базы данных. Представление связей, операции над данными в иерархической модели.
реферат [30,5 K], добавлен 22.02.2011Построение диаграмм, добавление деталей к описаниям операций, определение атрибутов классов и порядок генерации программного кода на языке С++ объектно-ориентированной модели информационной подсистемы, автоматизирующей работу регистратуры поликлиники.
курсовая работа [1,4 M], добавлен 25.06.2011Разработка объектно-ориентированной модели информационной подсистемы учета студентов университета во время экзаменационной сессии с помощью программы Rational Rose 2000, с использованием языка UML. Порядок генерации программного кода на языке С++.
курсовая работа [689,9 K], добавлен 21.06.2011Разработка объектно-ориентированной подсистемы складского учета для фирмы "КавказЮгАвто". Краткая характеристика предметной области. Построение диаграмм размещения, прецедентов, последовательности, компонентов и классов. Генерация программного кода C++.
курсовая работа [6,6 M], добавлен 26.06.2011Разработка элементов информационного обеспечения – логической модели реляционной и объектной баз данных с использованием метода диаграмм классов. Автоматизация процесса учета результатов анкетирования учащихся подразделения ВУЗа "Центр статистики".
курсовая работа [35,8 K], добавлен 28.01.2016Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.
реферат [57,1 K], добавлен 20.12.2010Этапы разработки объектно-ориентированной модели информационной подсистемы приемной комиссии для учета абитуриентов. Создание диаграмм для моделирования процесса обмена сообщениями между объектами. Порядок генерации программного кода на языке С++.
курсовая работа [429,3 K], добавлен 29.06.2011Технологии программирования. Сущность объектно-ориентированного подхода к программированию. Назначение Си, исторические сведения. Алфавит, базовые типы и описание данных. Структуры и объединения. Операторы Си++. Функции. Библиотека времени выполнения.
курс лекций [51,9 K], добавлен 03.10.2008Особенности исследования методик объектно-ориентированного проектирования программ с помощью языка UML по формализации, решению поставленной задачи, технологических приемов разработки объектно-ориентированных программ на языке Си++. Разработка программы.
контрольная работа [188,9 K], добавлен 22.10.2014
