Шпоры по ит. Ответы к экзамену по ИТ (1). Ответы к экзамену по ит
 Скачать 57.79 Kb.
|
|
Многомерная модель данных. Информация в многомерной модели представляется в виде многомерных массивов, называемых гиперкубами. В одной базе данных, построенной на многомерной модели, может храниться множество таких кубов, на основе которых можно проводить совместный анализ показателей. Конечный пользователь в качестве внешней модели данных получает для анализа определенные срезы или проекции кубов, представляемые в виде обычных двумерных таблиц или графиков. Основные понятия многомерных моделей данных: измерение и ячейка. Измерение – это множество однотипных данных, образующих одну из граней гиперкуба. В многомерной модели измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба. Ячейка – это поле, значение которого однозначно определяется фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам). Достоинством многомерной модели является удобство и эффективность анализа больших объемов данных, имеющих временную связь, а также быстрота реализации сложных нерегламентированных запросов. Недостаток этой модели в громоздкости в случае ее использования для решения стандартных задач оперативной обработки. Она, по сравнению с реляционными, не эффективно использует память, так как в ней резервируется место для всех значений, даже если некоторые из них будут отсутствовать Требования, предъявляемые к базе данных. Проектирование базы данных – это процесс создания проекта базы данных, предназначенной для поддержки функционирования экономического объекта и способствующей достижению его целей. Оно представляет собой трудоемкий процесс, требующий совместных усилий аналитиков, проектировщиков и пользователей. При проектировании базы данных необходимо учитывать тот факт, что база данных должна удовлетворять комплексу требований. Эти требования следующие: 1) целостность базы данных – требование полноты и непротиворечивости данных; 2) многократное использование данных; 3) быстрый поиск и получение информации по запросам пользователей; 4) простота обновления данных; 5) минимизация избыточности данных; 6) защита данных от несанкционированного доступа, искажения и уничтожения. Жизненный цикл базы данных. Жизненный цикл базы данных (ЖЦБД) – это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из семи этапов: 1) предварительное планирование; 2) проверка осуществимости; 3) определение требований; 4) концептуальное проектирование; 5) логическое проектирование; 6) физическое проектирование; 7) оценка работы и поддержка базы данных. 1. Предварительное планирование базы данных – важный этап в процессе перехода от разрозненных данных к интегрированным. На этом этапе собирается информация об используемых и находящихся в процессе разработки прикладных программах и файлах, связанных с ними. Она помогает установить связи между текущими приложениями и то, как используется их информация. Кроме того, позволяет определить будущие требования к базе данных. Информация документируется в виде обобщенной концептуальной модели данных. 2. Проверка осуществимостипредполагает подготовку отчетов по трем вопросам: 1) есть ли технология – необходимое оборудование и программное обеспечение – для реализации запланированной базы данных (технологическая осуществимость); 2) имеются ли персонал, средства и эксперты для успешного осуществления плана создания базы данных (операционная осуществимость); 3) окупится ли запланированная база данных (экономическая эффективность). 3. Определение требований: · цели базы данных; · информационные потребности различных структурных подразделений и их руководителей; · требования к оборудованию; · требования к программному обеспечению. 4. Концептуальное проектирование. Создаются подробные модели пользовательских представлений данных предметной области. Затем они интегрируются в концептуальную модель, которая фиксирует все элементы корпоративных данных, подлежащих загрузке в базу данных. Эту модель еще называют концептуальной схемой базы данных. 5. Логическое проектирование. Осуществляется выбор типа модели данных. Концептуальная модель отображается в логическую модель, основанную уже на структурах, характерных для выбранной модели. 6. Физическое проектирование. Логическая модель расширяется характеристиками, необходимыми для определения способов физического хранения базы данных, типа устройств для хранения, методов доступа к данным базы, требуемого объема памяти, правил сопровождения базы данных и др. 7. Оценка и поддержка базы данных. Оценка включает опрос пользователей на предмет выяснения, какие их информационные потребности остались неучтенными. При необходимости в спроектированную базу данных вносятся изменения. Пользователи обучаются работе с базой данных. По мере расширения и изменения потребностей бизнеса поддержка базы данных обеспечивается путем внесения изменений, добавления новых данных, разработки новых прикладных программ, работающих с базой данных. Этапы проектирования базы данных. Этапы проектирования БД: 1. Системный анализ и словесное описание информационных объектов предметной области и связей между ними. 2. Семантическое моделирование предметной области – частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, ER-модели. 3. Выбор стандартной СУБД. 4. Логическое проектирование БД, то есть описание БД в терминах принятой модели данных. На этом этапе определяются число и структура таблиц, формируются запросы к БД, определяются типы отчетных документов, разрабатываются алгоритмы обработки информации, создаются формы для ввода и редактирования данных и т.д. 5. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения максимального быстродействия при обработке данных. Модель «сущность-связь» (ER-модель), ее базовые понятия . Модельные представления, основанные на анализе семантики данных, иногда называют семантическими моделями. Одним из распространенных средств спецификации модельных представлений этого типа является т.н. «модель сущность – связь» (Entity – Relationship Model)]. Модель «сущность – связь» (ER-модель) была предложена П. Ченом в 1976 году [5] как средство «ручного» проектирования баз данных. Модель «сущность – связь» представляет собой набор концепций, используемых для описания логической структуры базы данных. Для модели «сущность – связь» базовыми являются понятия: - сущность; - связь; - атрибут. Модель «сущность – связь» основана на диаграммной технике. Для представления различных аспектов структуры данных (объектов, свойств объектов, связей между объектами, свойств связей и других) используются графические средства. В ER-модели абстрактным объектам реальной действительности соответствует понятие «сущность». Сущность – это абстрактный объект, который в конкретном контексте имеет независимое существование. Различают понятия «тип сущности» и «экземпляр сущности». Тип сущности (в дальнейшем просто сущность) представляет собой объект-тип, результат абстракции обобщения множества однородных объектовэкземпляров реальной действительности с одинаковыми свойствами. Сущность имеет семантически значимое имя, как правило, имя существительное, например: «Студент», «Преподаватель», «Сотрудник», «Отдел», «Компьютер, «Книга» и т. д. Экземпляр сущности соответствует объектам реальной действительности. Это конкретные персоны студентов, преподавателей, сотрудников, конкретные отделы на предприятии, конкретные компьютерные устройства, переплеты книг и т. д. Экземпляры сущностей уникальны, в природе не бывает двух одинаковых объектов. Следовательно, экземпляр сущности может быть идентифицирован уникальным образом. Связь – это ассоциация сущностей или отношение между сущностями. Различают понятия «тип связи» и «экземпляр связи». Тип связи (в дальнейшем просто связь) представляет собой отношение между типами сущностей. Связь имеет семантически значимое имя, как правило, в форме глагола, например: «Преподаватель» «Ведет» «Дисциплину», «Отдел» «Включает» «Сотрудника» и т. д. Экземпляр связи представляет собой отношение между экземплярами сущностей, например: Иванов «Ведет» Математику, Отдел 101 «Включает» Петрова и т. д. Связи обладают свойствами: - вид (категориальная, идентифицирующая, неидентифицирующая); - степень (унарная, бинарная, тернарная, N-арная); - кардинальность; - внешний ключ сущности. Атрибут – это свойство сущности или связи. Атрибутам как спецификаторам свойств сущностей или связей присваиваются семантически значимые имена, как правило, в форме существительного. Атрибутами сущности «Сотрудник» являются: табельный номер, фамилия, имя, отчество, дата рождения и другие персональные характеристики. Атрибутами тернарной связи «Экзамен» между сущностями «Студент», «Преподаватель», «Дисциплина» являются идентификационные номера студента, преподавателя и дисциплины, а так же время и место проведения экзамена. С понятием атрибута связаны понятия: - домен атрибута; - зависимости между атрибутами; - потенциальный ключ сущности; - детерминант и другие. 16.Преобразование ER-модели в реляционную модель данных. Процесс получения реляционной схемы базы данных из ER-диаграммы осуществляется по следующим правилам: 1. Каждая простая сущность превращается в отношение (таблицу). Простая сущность – это сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем отношения. 2. Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения. 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ отношения. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый идентификатор. 4. Атрибуты, имеющие типы связи M:1 (и 1:1) становятся внешними ключами. 5. В таблицах, построенных на основе ассоциаций, внешние ключи используются для идентификации участников ассоциации, а в таблицах, построенных на основе характеристик и обозначений, внешние ключи используются для идентификации сущностей, описываемых этими характеристиками и обозначениями. 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа: а) все подтипы размещаются в одной таблице; б) для каждого подтипа строится отдельная таблица. Полученные таблицы должны удовлетворять требованиям: · каждая таблица состоит из однотипных строк и имеет уникальное имя; · строки таблицы обязательно отличаются друг от друга хотя бы единственным значением поля, что обеспечивает однозначную идентификацию любой строки; · таблицы имеют фиксированное число столбцов и их значений; · в каждой таблице на пересечении строки и столбца должно находиться только одно значение или ничего; · в столбцах таблицы размещаются однородные значения данных. Важным этапом проектирования реляционной БД является обеспечение реляционной целостности данных. Реляционная целостность данных – это система правил, используемых для поддержания связей между записями (строками) в связанных таблицах, а также для обеспечения защиты от случайного удаления или изменения связанных данных. Существуют ограничения по условию целостности данных: · ограничение по сущностям – каждая строка должна отличаться от остальных ее строк значением хотя бы одного столбца; · ограничение по ссылкам – внешний ключ не может быть указателем на несуществующую строку той таблицы, на которую он ссылается. Чтобы обеспечить целостность, работа с данными должна производиться с учетом перечисленных далее правил. · Невозможно ввести в связанное поле подчиненной таблицы значение, отсутствующее в связанном поле главной таблицы. Однако можно ввести пустое значение, показывающее, что для данной записи связь отсутствует. · Не допускается удаление записи из подчиненной таблицы, если существуют связанные с ней записи в главной таблице. · Невозможно изменить значение поля в подчиненной таблице, если оно является ключевым в главной таблице. 17.Нормализация таблиц и нормальные формы. Нормализация - метод создания набора отношений с заданными свойствами на основе требований к данным, установленных в некоторой организации. Процесс нормализации был впервые предложен Э. Ф. Коддом. Нормализация часто выполняется в виде последовательности тестов с целью проверки соответствия (или несоответствия) некоторого отношения требованиям заданной нормальной формы. Сначала были предложены только три вида нормальных форм: первая (1НФ), вторая (2НФ) и третья (ЗНФ). Затем Р. Бойсом и Э. Ф. Коддом было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса-Кодда (НФБК). Все эти нормальные формы основаны на функциональных зависимостях, существующих между атрибутами отношения, Нормальные формы более высокого порядка, которые превосходят НФБК, были введены позднее. К ним относятся четвертая (4НФ) и пятая (5НФ) нормальные формы. Но на практике эти нормальные формы более высоких порядков используются крайне редко. Отношение было представлено как состоящее из некоторого количества атрибутов, а реляционная схема — из некоторого количества отношений. Атрибуты могут группироваться в отношения с образованием реляционной схемы на основе либо собственного опыта разработчика базы данных, либо посредством вывода реляционной схемы из разработанной ER-диаграммы. При использовании любого из этих двух подходов часто требуется применять определенный формальный метод, способный помочь проектировщику базы данных найти оптимальную группировку атрибутов для каждого отношения в схеме. Процесс нормализации является формальным методом, позволяющим определять отношения на основе их первичных или потенциальных ключей и функциональных зависимостей, существующих между их атрибутами. Проектировщики баз данных могут использовать нормализацию в виде наборов тестов, применяемых к отдельным отношениям с целью нормализации реляционной схемы до заданной конкретной формы, что позволит предотвратить возможное возникновение аномалий обновления. Нормализация — это формальный метод анализа отношений на основе их первичного ключа (или потенциальных ключей) и существующих функциональных зависимостей. Он включает ряд правил, которые могут использоваться для проверки отдельных отношений таким образом, чтобы вся база данных могла быть нормализована до желаемой степени. Если некоторое требование не удовлетворяется, то противоречащее данному требованию отношение должно быть разделено на отношения, каждое из которых (в отдельности) удовлетворяет всем требованиям нормализации. Чаще всего нормализация осуществляется в виде нескольких последовательно выполняемых этапов, каждый из которых соответствует определенной нормальной форме, обладающей известными свойствами. В ходе нормализации формат отношений становится все более ограниченным (строгим) и менее восприимчивым к аномалиям обновления. Связь нормальных форм При работе с реляционной моделью данных важно понимать, что для создания отношений приемлемого качества обязательно только выполнение требований первой нормальной формы (1НФ). Все остальные формы могут использоваться по желанию проектировщиков. Но для того чтобы избежать аномалий обновления, нормализацию рекомендуется выполнять как минимум до третьей нормальной формы (ЗНФ). На рисунке показана взаимосвязь между различными нормальными формами. Согласно этому рисунку, некоторые отношения в форме 1НФ могут находиться также в форме ЗНФ, отношения 2НФ — в форме ЗНФ и т.д. Предположим, что задано множество функциональных зависимостей для каждого от этого рисунка. Схема взаимосвязей между отдельными нормальными формами ношения и что в каждом отношении имеется назначенный первичный ключ. Эта информация имеет исключительно важное значение для нормализации и служит для проверки того, находится ли отношение в определенной нормальной форме. |