Шпаргалка по "Информатике"

18. Объектно-ориентированная модель  данных (Object-oriented Data Model - OODM). Ее базовые понятия (объекты, классы, методы, наследование, инкапсуляция, расширяемость, полиморфизм), достоинства и недостатки

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

Класс объекта = интерфейс (виден  другим объектам) + закрытая область. Интерфейс класса = свойства класса + методы класса. Св-ва (атрибуты) значения, характеризующие объект в его классе. Определяют состояние объекта. Напр., у счета – категория, баланс, кредит. К св-вам относятся также связи с другими объектами. Св-ва объектов описываются одним из стандартных типов (напр., строковым String) либо типом, кот. конструирует пользователь (Class). Св-ва сами могут быть объектами, что позволяет создавать составные объекты, напр., св-во ФИО может состоять из св-в: фам., имя, отч. Методы (программные коды, процедуры, с пом. кот. можно получить доступ к данным) определяют поведение объектов. Напр., клиент может сделать заказ, оплатить счет и т.п. – для каждого вида деятельности отдельный метод. Обычно имеют форму операций и функций с параметрами. На уровне интерфейса видно только имя каждого метода и требуемые параметры. В БД только через методы возможен доступ к данным (вне них внутренняя структура объекта скрыта от пользователя). В закрытой области могут существовать дополнительные свойства с закрытыми значениями, а также скрытые связи и сообщения другим объектам.

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

Между записями БД и функциями  их обработки устанавливаются связи  с помощью ОО механизмов: Инкапсуляция означает объединение в объекте данных и методов, а также скрытие данных внутри объектов (что повышает надежность). Доступ к объекту только через его интерфейс (методы). Наследование (разбиение на подтипы) распространяет множество свойств и методов на всех потомков объекта (новые классы или объекты).  Однако можно добавить дополнительные свойства и методы. Напр., классы Мужчина и Женщина как наследующие класс Человек. Полиморфизм допускает в объектах разных классов иметь методы с одинаковыми именами, но различно реагирующих на одинаковые события. Для унификации обработки разнородных объектов. Напр., метод «Печать результата»

Используются для высокопроизводительной обработки данных, имеющих сложную  структуру. БД позволяет совместно  использовать объекты различными приложениями и пользователями. Поиск в ОО БД состоит в установлении сходства между объектом, задаваемым пользователем (объект-цель), и объектами, хранящимися  в БД. Примеры ООСУБД: POET, Jasmine, Orion, Iris, Versant, O2, ODB-Jupiter.

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

«-»: Сложность понятийного  аппарата, что затрудняет применение и отрицательно сказывается на накоплении опыта конструирования и эксплуатации. Низкая скорость выполнения запросов.

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

«-»: У ОРМД и ООМД  отсутствуют в отл. от рел. МД унифицированная теория, формальная методология проектирования БД (как нормализация), специальные средства создания запросов, общие правила определения целостности и др.

«+»: ООМД и ОРМД для преодоления ограниченных возможностей РМД по хранению и обработке сложных объектов (документы, звук, видео, графика,…)

19. Объектно-реляционная (расширенная  реляц.) модель данных (object-relational database ORD; Extended Relation Data Model – ERDM) ее достоинства и недостатки

ОР модель основана на стратегии  РМД (что обеспечивает простоту ее структуры), однако учитывает объектные свойства данных, являясь, т.о., гибридной моделью. В ОРМД используются объ.-ориент. компоненты: пользовательские типы данных, инкапсуляция, полиморфизм, наследование, переопределение методов и т.п. Основные характеристики ОРМД определены стандартом SQL-3 (2003). Классы ООМД соответствуют таблицам в ОРБД, а объекты – записям в таблице. Для каждого наследуемого класса созд.ся отдельная таблица, связанная  с таблицей базового класса по первичному ключу отношением 1:1. Перв.кл. (напр., поле с автонумерацией) является идентификатором объекта. Базовый класс должен уметь выполнять создание, загрузку, сохранение, удаление единичных объектов, изменение и удаление множеств объектов. ОРСУБД поддерживают язык SQL.

ОРМД наиболее приспособлена для бизнес-приложений. В будущем может произойти слияние OOМД и  ОРМД.

ОРСУБД: Informix Universal Server, Oracle8, DB2, CUBRID, OpenLink Virtuoso.

 «+»: возможность обработки  больших объемов данных, быстродействие, широкие возможности масштабирования,  функциональность (добавление отдельных  интерфейсов и подсистем сервера)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

20. Многомерная модель данных, ее  базовые  понятия (измерение,  ячейка),  достоинства и недостатки

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

В БД может храниться несколько  кубов. Пользователь получает срезы (проекции) кубов в виде обычных двумерных  таблиц или графиков. Операции: срез (сечение) подмножество в р-те фиксации одного/неск. измерений, вращение представление данных, сгруппированных по новому набору измерений, агрегация [детализация] объединение [разбиение] значений нескольких измерений (напр., от уровня «Город» до уровня «Страна»)

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

СУБД: Essbase (от Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle; поликуб.), Cache (InterSystems); Media/MR (Speedware; РМД+ММД).

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

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

21. Понятие проектирования базы  данных. Требования, предъявляемые  к БД

Пр. БД процесс создания проекта БД, предназначенной для поддержки функционирования экономического объекта и способствующей достижению его целей.  Трудоемкий процесс, требующий совместных усилий аналитиков, проектировщиков и пользователей. Созданная БД должна удовлетворять информационные потребности различных категорий пользователей за ограниченный промежуток времени, в определенном месте и в определенном виде. Требования к БД: 1)целостность требование полноты и непротиворечивости данных; 2)многократное использование данных; 3)быстрый поиск и получение информации по запросам; 4)простота обновления данных; 5)минимизация избыточности данных; 6)защита данных от несанкционированного доступа, искажения и уничтожения.

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

Этапы пр.:

Концептуальное  пр. Цель: создание конц. модели данных исходя из представлений пользователей о предметной области (1)анализ требований к БД разных пользователей (2) моделирование связей сущностей (определение, ER) и нормализация (3) проверка модели (правила ввода, обновления и удаления, проверка отчетов, запросов, представлений, целостности совместного использования и безопасности (4) пр. распределенной БД (определение местоположения таблиц, требований, доступа и стратегии фрагментирования)

Выбор ПО СУБД Факторы: стоимость; инструментальные средства и возможности; тип модели данных, переносимость, требования к оборудованию

Логическое пр. Результат: (1) логич. структура БД – схема, описанная в терминах языка представления данных (2)функциональные спецификации программных модулей и набор возможных запросов к БД | Процедуры: (1) определение таблиц и их документирование (2) проверка логических модулей данных на предмет возможности выполнения всех транзакций (3) определение требований поддержки целостности данных (4) созд. окончательного варианта логич. модели

Физическое пр. Цель: описание конкретной реализации БД, размещаемой во внешней памяти комп.

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

22. Этапы жизненного цикла базы данных.

Жизненный цикл БД – процесс проектирования, реализации и поддержки БД. Состоит из 7 этапов:

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

2 проверка осуществимости (подготовка отчетов по 3 вопр: есть ли технология, персонал и средства для успешн осущ-ния плана созд БД, эк эффективность);

3 определение требований (цели БД; инф потребности различ структур подразделений и их руководит; требования к оборудованию, к ПО);

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

5 логическое проектирование (выбор типа модели данных);

6 физическое проектирование (логич модель расшир характ-ками, необход для определения способов физич хранения БД, типа устройств для хранен,  методов доступа к данным базы, требуемого объема памяти);

7 оценка работы и поддержка БД (что не учли, внесен изменен, доб новые данные, разработка новых приклад программ, работающ с БД)

23 Модель "сущность–связь" (ER-модель) - средство модел-ния предметной области на этапе концептуальн проектир. В ней модел-ние базир на исп графич средств – ER-диаграмм. Они предст-ют связи между сущностями. Сущность – некоторый объект реал мира, кот может сущ-ть независимо. Сущность имеет экземпляры, отлич-ся друг от друга значениями атрибутов и допускающие однозначную идентификац. Атрибут – это св-во сущности. Напр, сущность КНИГА характ-ся такими атрибутами, как автор, наименование, цена, издательство, тираж, кол-во стр. Конкретные книги - экземпляры сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом "наименование". Атрибут, кот уникал образом идентифицирует экземпляры сущности - ключ. Может быть составной ключ, представл комбинацию нескольких атрибутов. На ER диагр сущность предст-ся прямоугольн, в кот указ-ся ее имя. Сущ-ют связи между сущностями. Связь - взаимодействие между сущностями. Она характ-ся мощностью, кот показ, сколько сущностей участвует в связи. На ER-диаграмме связь изобр-ся ромбом.

24 Типы связи, их представление на ER-диаграмме

Связь - взаимодействие между сущностями. Каждая связь может иметь один из следующих типов связи: 1:1, 1:М, M:N. Связь типа 1:1 означает, что 1 экземпляр первой сущности связан с 1 экземпляром второй сущности.( МЕНЕДЖЕР  – УПРАВЛЯЕТ – ФИЛИАЛ. Т.к. менеджер управл только 1 филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с 1 экземпляром сущности ФИЛИАЛ.) Связь типа 1:М означает, что 1 экземпляр первой сущности связан с несколькими экземплярами второй сущности. ( ФИЛИАЛ  – ОБРАБАТЫВАЕТ – СЧЕТ. Т.к. филиал обрабатывает несколько счетов, а счет обрабатывается только 1 филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с 1 экземпляром сущности СЧЕТ, а каждый экземпляр сущности СЧЕТ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ.) Связь типа М:N означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. (КЛИЕНТ  – ИМЕЕТ – СЧЕТ Т.к. счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то каждый экземпляр сущности СЧЕТ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности СЧЕТ.). Тип связи M:N является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа 1:М путем создания промежуточной сущности.