ПОСТРЕЛЯЦИОННАЯ МОДЕЛЬ, ЕЕ ДОСТ-ВА И НЕД-КИ.

⇐ ПредыдущаяСтр 2 из 4Следующая ⇒

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

18.ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ МОДЕЛЬ ДАННЫХ. ЕЕ БАЗ. ПОНЯТИЯ ДОСТОИНСТВА И НЕДОСТАТКИ.

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

19. ОБЪЕКТНО-РЕЛЯЦ. МОДЕЛЬ ДАННЫХ. «+» И «-»

В связи со значительным усложнением приложений появилась новая модель – расширенная реляционная модель (Extended Relation Data Model –ERDM). Эта модель вкл. в себя осн. достоинства объектно-ориентированной модели и одновременно унаследовала простоту структуры реляционных моделей, и потому стала называться объектно-реляционной моделью данных. В отличие от объектно-ориентированной модели (OODM) объектно-реляц. модель (ERDM) осн-на на стратегии реляц-й модели, в то время как объектно-ориентир. модель основана на объектной стратегии. Исходя из этого, объектно-реляц. наиболее приспособлена для бизнес-приложений, а объектно-ориентир. исп-ся в спец-х инженерных и научн. приложениях. Некот. спец-ты полаг-ют, что в будущем произойдет слияние этих 2-ух моделей.

Однако у объектно-реляц. и объектно-ориентир. моделей есть и ряд недостатков, осн-е из к-х след:

· отсутствие унифицированной теории, которая есть в реляционных моделях;

· отсутствие формальной методологии проектир-я БД, как нормал-ция в реляц-х базах;

· отсутствие специальных средств создания запросов;

· отсутствие общих правил определения целостности и др.

20. МНОГОМЕРНАЯ МОДЕЛЬ ДАННЫХ, ЕЕ БАЗ. ПОНЯТИЯ (ИЗМЕРЕНИЕ, ЯЧЕЙКА), «+» И «-».

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

Основные понятия, с кот. работает пользователь в многомерной модели: 1)Измерение (мн-во однотипных данных, образ-щих одну из граней гиперкуба (дни, месяцы, районы, регионы и т.д.)) 2)Ячейка (поле, значение кот-го однозначно определяется фиксированным набором измерений)

Для многомерной модели применяются специальные операции: 1)Срез – это подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. 2) Вращение изменяет порядок измерений при визуальном представлении данных (меняются местами оси ОХ и ОУ). 3) Агрегация и детализация означают соответственно переход к более общему и более детальному представлению данных.(например в кубе имеется иерархия подразделение-регион-страна, тогда получ. данные не только по отдельному подразделению, но и по целой стране – агрегация и наоборот)

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

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

21.ПОНЯТИЕ ПРОЕКТИР-НИЯ Бд. ТРЕБ-НИЯ, ПРЕДЪЯВЛЯЕМЫЕ К Бд.

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

22.ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА БАЗЫ ДАННЫХ.

Жизненный цикл базы данных (ЖЦБД) – это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из семи этапов:1. Предварительное планирование БД – важный этап в процессе перехода от разрозненных данных к интегрированным. На этом этапе собирается информация об используемых и находящихся в процессе разработки прикладных программах и файлах, связанных с ними. Информация документируется в виде обобщенной концептуальной модели данных. 2. Проверка осуществимости предполагает подготовку отчетов по трем вопросам:1) (технологическая осуществимость): есть ли необх. оборудование и прогр. обеспеч. для реализ. запланир. БД; 2) (операционная осуществимость): имеются ли персонал, ср-ва и эксперты для успешного осуществлен. плана создания БД; 3) (экономическая эффективность): окупится ли запланирован. БД. 3. Определение требований. определяются:· цели базы данных; ·информационные потребности различных структурных подразделений и их руководителей; ·требования к оборудованию; ·требования к программному обеспечению. 4.Концептуальное проектирование. создаются подробные модели пользовательских представлений данных предметной области. Затем они интегрируются в концептуальную модель, которая фиксирует все элементы корпоративных данных, подлежащих загрузке в БД. 5.Логическое проектирование. осуществляется выбор типа модели данных. Концептуальная модель отображается в логическую модель, основанную уже на структурах, характерных для выбранной модели. 6.Физическое проектирование. логическая модель расширяется характеристиками, необходимыми для определения способов физического хранения базы данных, типа устройств для хранения, методов доступа к данным базы, требуемого объема памяти, правил сопровождения БД и др.7.Оценка и поддержка БД. Оценка включает опрос пользователей на предмет выяснения, какие их информационные потребности остались неучтенными. При необходимости в спроектированную БД вносятся изменения. Пользователи обучаются работе с БД. По мере расширения и изменения потребностей бизнеса поддержка БД обеспечивается путем внесения изменений, добавления новых данных, разработки новых прикладных программ, работающих с БД.

23. МОДЕЛЬ "СУЩНОСТЬ-СВЯЗЬ", ЕЕ ПОНЯТИЯ. ПРЕДСТАВЛЕНИЕ СУЩНОСТИ И СВЯЗИ НА ER-ДИАГРАММЕ.

Средством моделирования предметной области на этапе концептуального проектирования является модель "сущность–связь". Часто ее называют ER-моделью (Entity – сущность, Relation – связь). В ней моделирование структуры данных предметной области базируется на исп-нии графических средств – ER-диаграмм (диаграмм "сущность–связь"). В наглядном виде они представляют связи между сущностями.

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

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

В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE-средствах. Эти средства предназначены для автоматизированного проектирования реляционных баз данных.

24.ТИПЫ СВЯЗИ, ИХ ПРЕДСТАВЛЕНИЕ НА ER-ДИАГРАММЕ.

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

Важной хар-кой связи явл-ся тип связи (кардинальность).

Если каждый экземпляр сущности А может быть связан не более чем с одним экз-м сущности В,то в этом случае связь имеет тип "один-к-одному" (1:1).

Если каждый экз сущности А может быть связан более чем с одним экз-м сущности В, а каждый экз сущности Вможет быть связан не более чем с одним экз-м сущности А, то в этом случае связь имеет тип "один-ко-многим" (1:М).

Если каждый экз сущности А может быть связан с неск-ми экз сущности В и каждый экз сущности В может быть связан с неск.экз сущности А, то в этом случае связь имеет тип "многие-ко-многим" (М:N).

25. КЛАСС ПРИНАДЛЕЖНОСТИ СУЩНОСТИ, ЕГО ПРЕДСТАВЛЕНИЕ НА ER-ДИАГРАММЕ.

Если каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является обязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным в прямоугольник, смежный с прямоугольником сущности А. -Если не каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является необязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным на линии связи возле прямоугольника сущности А.

26.ПРАВИЛА ПРЕОБР. ER-ДИАГРАММ В РЕЛЯЦ. ТАБЛИЦЫ В СЛУЧАЕ СВЯЗИ 1:1.

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

Правила генерации таблиц из ER-диаграмм опираются на два осн. фактора – тип связи и класс принадлежности сущности: 1)Если связь типа 1:1 и класс принадлежности обеих сущностей является обязательным, то необх-ма только одна таблица. Первичным ключом этой таблицы может быть первичный ключ любой из двух сущностей. 2) Если связь типа 1:1 и класс принадлежности одной сущности является обязательным(наз. дочерняя), а другой – необязательным(наз. родительская), то необходимо построить таблицу для каждой сущности. Первичный ключ сущности д.б. первичным ключом соотв-щей таблицы. Первич. ключ сущности, для которой класс принадл-ти явл. необязат-ым, добавляется как атрибут в таблицу для сущности с обязат. классом принадл-ти. Если внешний ключ представляет связь 1:1, то должны быть запрещены его дублирующие значения. Первич. ключ родит. сущности, помещаемый в таблицу, представляющую дочернюю сущность, наз-ся внешним ключом родит. сущности. 3)Если связь типа 1:1 и класс принадл-ти обеих сущ-тей явл-ся необязательным, то необх. построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности д. б. перв.ключом соотв-щей таблицы. Таблица для связи среди своих атрибутов д. иметь ключи обеих сущностей.

27.ПРАВИЛА ПРЕОБРАЗОВАНИЯ ER-ДИАГРАММ В РЕЛЯЦИОННЫЕ ТАБЛИЦЫ В СЛУЧАЕ СВЯЗИ 1:М, М:N.

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

2) Если связь типа 1:М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

3)Для связи типа М:N класс принадлежности сущности не имеет значения. Если связь типа М:N, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

28.НОРМАЛИЗАЦИЯ ТАБЛИЦ, ЕЕ ЦЕЛЬ. ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА. ВТОРАЯ НОРМАЛЬНАЯ ФОРМА. ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА.

Реляционная база данных считается эффективной, если она обладает характеристиками: 1. Минимизация избыточности данных. 2. Минимальное использование отсутствующих значений (Null-значений). 3. Предотвращение потери информации.

Минимизировать избыточность данных позволяет процесс, называемый нормализацией таблиц. Ее суть сводится к приведению таблиц к той или иной нормальной форме. Были выделены три нормальные формы – 1НФ, 2НФ, 3НФ. Каждая последующая нормальная форма вводит определенные ограничения на хранимые в базе данные. Реляционная база данных считается эффективной, если все ее таблицы находятся как минимум в 3НФ. Определение 1НФ. Таблица находится в 1НФ, если все ее поля содержат только простые неделимые значения. Определение 2НФ. Таблица находится в 2НФ, если она удовлетворяет требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа. Функциональная зависимость – это понятие, отображающее определенную семантическую связь между полями таблицы. Неключевое поле А функционально полно зависит от первичного ключа, если: · оно функционально зависит от первичного ключа, т.е. каждой комбинации значений полей первичного ключа соответствует одно и только одно значение поля А. · не существует функциональной зависимости А ни от какого подмножества полей первичного ключа (в противном случае А находится в частичной функциональной зависимости от первичного ключа). Определение 3НФ. Таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей. Транзитивная зависимость -функциональная зависимость между неключевыми полями.

29. КОНЦЕПТ. ПРОЕКТИРОВАНИЕ. ЦЕЛЬ И ПРОЦЕДУРЫ

Цель этапа концепт. проект-ния – создание концепт-й модели данных исходя из представлений польз-лей о предметной обл-ти. Для ее достижения вып-ся ряд послед-ых процедур.

1. Опр-е сущностей и их документир-ние. Для идентиф-ции сущностей опр-ся объекты, кот. сущ-ют незав-мо от др. Такие объекты явл-ся сущностями. Кажд. сущности присв-ся осмысл-е имя, понятное польз-лям. Имена и описания сущностей заносятся в словарь данных. Уст-ся ожидаемое кол-во экземпляров каждой сущности.

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

3. Созд-е ER-модели предм. обл-ти. Для предст-ния сущностей и связей м/у ними исп-ся ER-диаграммы. На их основе созд-ся единый образ моделир-й предм. обл-ти – ER-модель предм. обл-ти.

4. Опр-е атрибутов и их документ-е. Выявл-ся все атрибуты, опис-щие сущности созд-й ER-модели. Каждому атрибуту присв-ся осмысл. имя, понятное польз-лям. О кажд. атрибуте в словарь данн. помещ-ся след. свед-я: имя атрибута и его описание; тип и размерность знач-й; знач-е, прин-мое для атрибута по умолчанию; явл-ся ли атрибут составным, из каких прост. атрибутов он состоит. (Напр, атрибут "Ф.И.О. клиента" м.состоять из прост. атрибутов "Фам", "Имя", "Отч", а м. б. простым, сод-щим единые знач-я, как "Сидорский Евгений Михайлович".

5. Опр-е знач-й атрибутов и их документ-е. Для кажд. атрибута сущности, уч-щей в ER-модели, опр-ся набор доп-х знач-й и ему присв-ся имя. Напр, атрибут "Тип счета" м. иметь только знач-я "депозитный", "тек-й", "до востреб-я", "карт-счет.

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

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

30. ЛОГИЧ. ПРОЕКТ-Е, ЕГО ЦЕЛЬ И ПРОЦЕДУРЫ.

Цельэтапа логич. проект-я – преобраз-е концепт. модели на основе выбранной модели данных в логич. модель, не завис-ю от ос-тей исп-й в дальнейшем СУБД для физ. реализ-ии БД. Для ее достижения выполняются следующие процедуры. 1. Выбор модели данных. Чаще выбир-ся реляц. модель данных в связи с наглядностью табл. предст-я данных и удобства работы с ними. 2. Опр-е набора таблиц исходя из ER-модели и их док-ние. Для каждой сущности ER-модели создается таблица. Имя сущности – имя таблицы. Осущ-ся форм-ние структуры таблиц. Устанавливаются связи между таблицами посредством мех-зма первичных и внешних ключей. Стр-ры таблиц и установл-е связи между ними докум-ся. 3. Нормализация таблиц. На этом шаге коррект-щик проверяет корректность стр-ры таблиц, созданных на предыдущем шаге, посредством прим-я к ним процедуры нормализации. Она закл-ся в приведении каждой из таблиц, по крайней мере, к 3НФ. 4. Проверка логич. модели данных на предмет возм-сти вып-я всех транзакций, предусм-ных польз-ми. Транзакция – это набор действий, выполняемых отдельным польз-лем или прикладной программой с целью изм-я содержимого БД. 5. Опр-е требований поддержки целостности данных и их докум-ние. Эти треб-я предст. соб. ограничения, кот. вводятся с целью предотвратить помещение в БД противоречивых данных. Д. б. рассм-ны след. типы ограничений: 1)обязательные данные. Выясняется, есть ли атрибуты, к. не м. иметь Null-знач-й; 2)ограничения для значений атрибутов. Опр-ся допустимые знач-я для атрибутов; 3)целостность сущностей. Она достигается, если первичный ключ сущности не содержит Null-значений; 4)ссылочная целостность. Она понимается так, что значение внешнего ключа должно обязательно присутствовать в первичном ключе одной из строк таблицы для родительской сущности; 5) ограничения, накладываемые бизнес-правилами. Например, в случае с проектом БАНК может быть принято правило, запрещающее клиенту распоряжаться, скажем, более чем тремя счетами. Сведения обо всех установленных ограничениях целостности данных помещаются в словарь данных.

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

31.ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ, ЕГО ЦЕЛЬ И ПРОЦЕДУРЫ.

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

1. Проектирование таблиц БД ср-ми выбранной СУБД. Глубоко изучаются ее функц-ные возм-сти по проект-ию таблиц; вып-ся проект-ние таблиц и схемы их связи в среде СУБД. 2.Реализация бизнес-правил в среде выбранной СУБД.Обновление инфо в таблицах м. б. ограничено бизнес-правилами. Сп-б их реализации зав. от выбр-ой СУБД. Одни с-мы для реализации треб-ий предм-ой области предлаг. больше возм-стей, другие – меньше. В нек. с-мах вообще отс-ует поддержка реал-ции бизнес-правил. В так. случае разраб-ся приложения для реал-и их ограничений. Все решения, принятые в связи с реал-цией бизнес-правил предм-ой обл-ти, подробно опис-ся в сопров-ой док-ции. 3.Проектирование физ-ой организации БД.Выб-ся наилучшая файловая организация для таблиц, выявл-ся транзакции, кот.будут вып-ся в проектируемой БД, выдел-ся наиболее важные из них. Транзакция – это набор действий, выполняемых отдельным польз-лем или прикладной программой с целью изм-я содержимого БД Анализируется пропускная способность транзакций- кол-во транзакций, кот. м. б. обработаны за зад-ый инт. времени, время ответа -пром-к времени, необх.для вып-ия 1ой транзакции. Стремятся к повышению пропускной сп-сти транзакций и умен-нию времени ответа. На основании указ-х пок-ей приним-ся решения об оптим-ии произв-сти БД путем опр-ия индексов в таблицах, ускор-их выборку данных из базы. Пров-ся оценка дисков. объема памяти, необх-го для размещения созд-емой БД. Стремятся к его мин-ции. Прин-е реш-я по излож-м вопросам док-ся.

4.Разработка стратегии защиты БД.

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

33. CASE-СРЕДСТВА ДЛЯ МОДЕЛИРОВАНИЯ ДАННЫХ.

В связи с наглядностью представления концептуальных схем БД ER-модели получили широкое распространение в CASE-средствах. Эти средства предназначены для автоматизированного проектирования реляционных баз данных.

Широко распространены CASE-системы, позволяющие выполнять ER-диаграммы в соответствии со стандартом IDEF1X. К ним относятся, в частности, Erwin, Power Designer.

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

Современные CASE-средства обладают, например, такими характерными особенностями, как:

- единый графический язык;

-использование репозитария – это база данных проекта;

-поддержка коллективной разработки и управления проектом;

-макетирование;

-генерация документации;

-верификация проекта;

34.ПОНЯТИЕ СУБД. АРХИТЕКТУРА СУБД.

СУБД – совок-сть языков. и программн. ср-в, предназнач. для создания, ведения и совместного использования БД многими пользователями.

Архитектура системы – представление о совок-ти функцион. компонентов системы и их взаимосвязях.

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

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

Современная СУБД содержит в своем составе программн. средства создания БД, средства работы с данными и сервисные средства. В среде СУБД можно выделить 5 осн. компонентов: аппаратное обеспечение, программное обеспечение, данные, процедуры и пользователи. Пользователи: клиенты БД, администратор БД, прикладные программисты.

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

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

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

35. ВОЗм-ТИ, предост-ые СУБД польз-ям И ПРОИЗВОДИТЕЛЬНОСТЬ СУБД.

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

36.КЛАС-ЦИЯ СУБД. РЕЖИМЫ РАБОТЫ ПОЛЬ-ЛЯ.

Клас – ция:

1)По степени универс-ти: общего и спец. назнач-ия.

2) По типу модели данных, поддерживаемому СУБД: -иерархические. Первая иерарх.СУБД - система IMS коммерч. распр-ние кот. нач-сь в 1968 г.; - сетевые. Первая сетевая СУБД - система IDS - разраб. компанией General Electric немного позже системы IMS; - реляционные- первые реляц-ые СУБД Sysyem R; - постреляционные - продолжают исп-ть стандартн. язык запросов для реляц. БД – SQL, но с объектными расширениями; - объектно-ориентированные. В их основе лежит объектно-ориентированная модель обработки данных. - многомерные, в основе к-ых лежит многомерная модель данных.

3) На общем уровне все: - профессиональные (промышленные), к-ые предст. собой программн. основу для разработки автоматизированных систем упр-ния крупными эк-кими объектами (DB2, Sybase, Progress).

- персональные (настольные). Ориент-ны на решение задач локального пользователя или компактной группы поль-лей и предназ-ны для исп-ния на ПК, это объясняет их второе название – настольные. DBASE, FoxBase, FoxPro, Clipper, Paradox, Access.

В наст. время среди СУБД выделяют СУБД (условно говоря) промежуточные между профессиональными и персональными (Microsoft SQL Server).

4) по поддерживаемому режиму работы:Однопользовательские и Многопользовательские (с мультидоступом).

Дата добавления: 2018-04-15; просмотров: 425; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 123 4 Следующая ⇒

Мы поможем в написании ваших работ!