Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Восходящее проектирование и нисходящее проектирование.
Пример проектирования реляционной БД Постановка задачи Задача проектирования БД для предметной области состоит в том, чтобы обеспечить поддержку не только любых ныне используемых, но и будущих приложений. Таким образом, БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и создания приложений, для которых невозможно заранее определить требования к данным. Это позволяет в дальнейшем строить на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без переписывания старых приложений. С другой стороны, основывая проектирование БД на реализации текущих и видимых задач, можно существенно ускорить создание информационной системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Однако по мере количества таких информационных систем быстро увеличивается число прикладных БД и, соответственно, резко возрастает уровень дублирования данных и повышается стоимость их ведения. Желание достичь одновременно гибкости и эффективности приводит к тому, что в общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной – для ее совершенствования с целью повышения эффективности обработки данных. При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей. Сбор данных начинается с выявления и изучения объектов информационной среды и процессов, в которых эти объекты участвуют. Объекты (сущности) группируются по типу и по мощности связей между ними (студент – сессия, преподаватель – дисциплина и т.д.). Дальнейшая задача проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Такой проект БД можно создать, используя методологию нормализации отношений. Рассмотрим следующую задачу: пусть необходимо обеспечить сбор и обработку данных по результатам сдачи экзаменов и зачетов студентами факультета. Организация данных должна обеспечивать (слайд 2):
выполнение текущего учебного плана; формирование ведомостей по отдельным дисциплинам для групп студентов; формирование листов зачетных книжек студентов; формирование сводной ведомости курса; расчет среднего балла по дисциплинам и т.п.
13.2. Восходящее проектирование (универсальное отношение) Проектирование БД на основе описания предметной области в виде сводной таблицы (технология восходящего проектирования) предполагает выявление необходимого набора атрибутов – характеристических свойств объектов таким образом, чтобы каждый из этих атрибутов имел в базе данных уникальное имя, и представление этих атрибутов в виде двумерной таблицы. Перечислим набор атрибутов, необходимый для обеспечения перечисленных в постановке задачи функций, в виде универсального отношения (слайд 3): Сессия (ФИО студента, № зачетной книжки, Дисциплина, Семестр, Форма отчетности, Количество часов, Оценка, Дата сдачи, ФИО преподавателя, Должность преподавателя, Кафедра). Применим правила нормализации к универсальному отношению «Сессия» (слайд 4). 1. Определение первичного ключа таблицы. Предположим, что каждый студент сдает один раз экзамен (зачет) по дисциплине учебного плана и получает оценку. Дисциплина учебного плана однозначно характеризуется наименованием, номером семестра, за который отчитывается студент, и формой отчетности (т.к. учебный план предусматривает сдачу и экзамена, и зачета по одной и той же дисциплине в рамках одного семестра). Тогда в качестве первичного ключа отношения «Сессия» можно использовать следующий набор атрибутов: № зачетной книжки, Дисциплина, Семестр, Форма отчетности. 2. Выявление атрибутов, функционально зависящих от части составного ключа. Каждый из атрибутов - ФИО преподавателя, Должность преподавателя, Кафедра и Количество часов - функционально зависит только от атрибутов Дисциплина, Семестр и Форма отчетности, т.е. этот атрибут вместе с совокупностью атрибутов первичного ключа составит вторую таблицу:
Учебный план (Дисциплина, Семестр, Форма отчетности, Количество часов, ФИО преподавателя, Должность преподавателя, Кафедра). Из исходной таблицы при этом удаляются атрибуты ФИО преподавателя, Должность преподавателя, Кафедра и Количество часов: Сводная ведомость (ФИО студента, № зачетной книжки, Дисциплина, Семестр, Форма отчетности, Оценка). Составной первичный ключ, повторяющийся в обеих таблицах, приводит к избыточности при дублировании информации сразу трех столбцов, поэтому кажется целесообразным ввести дополнительный атрибут - № (порядковый номер) – в таблицу «Учебный план» и использовать именно его в качестве первичного ключа. Тогда таблицы примут следующий вид: Учебный план (№ Уч. план, Дисциплина, Семестр, Форма отчетности, Кол-во часов, ФИО преподавателя, Должность преподавателя, Кафедра). Сводная ведомость (ФИО студента, № зачетной книжки, № Уч. план, Оценка). В таблице «Сводная ведомость» осталась еще одна частичная функциональная зависимость: № зачетной книжки → ФИО студента. Ликвидировав эту зависимость, получим еще одну таблицу – «Студенты»: Студенты (№ зачетной книжки, ФИО студента) Ликвидация ФЗ приведет к изменению таблицы «Результаты сессии»: Сводная ведомость (№ зачетной книжки, № Уч. план, Оценка) 3. Выявление транзитивных зависимостей В таблице «Учебный план» выявляются следующие транзитивные зависимости: № Уч. план → ФИО преподавателя ФИО преподавателя → Должность преподавателя ФИО преподавателя → Кафедра Применив второй шаг процедуры нормализации, получим таблицу «Преподаватели»: Кадровый состав (ФИО преподавателя, Должность преподавателя, Кафедра) Следует иметь в виду, что в этом случае в рамках ПрО считается, что атрибут ФИО преподавателя однозначно (уникально) характеризует конкретного преподавателя. Итак, получили следующую декомпозицию (слайд 5): Учебный план (№ Уч. план, Дисциплина, Семестр, Форма отчетности, Кол-во часов, ФИО преподавателя) Студенты (№ зачетной книжки, ФИО студента) Кадровый состав (ФИО преподавателя, Должность преподавателя, Кафедра) Сводная ведомость (№ зачетной книжки, № Уч. план, Оценка)
Такой декомпозиции на самом деле достаточно для того, чтобы преобразовать исходную таблицу к совокупности нормализованных таблиц (все полученные таблицы приведены к 3НФ и к НФБК). Нисходящее проектирование
|
||||||
Последнее изменение этой страницы: 2021-12-07; просмотров: 71; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.216.53.143 (0.008 с.) |