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

 

25 Класс принадлежности сущности,  его представление на ER-диаграмме.

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

 На ER-диаграмме 1 класс принадлежности  обеих сущностей необязат. На ER-диаграмме 2 класс принадлежности  сущности  КЛИЕНТ обязат, а сущности СЧЕТ необязат. На ER-диаграмме 3 класс принадлежности  сущности  КЛИЕНТ необязат, а сущности СЧЕТ обязат. На ER-диаграмме 4 класс принадлежности  обеих сущностей обязательный.  

26.Правила  преобразования  ER-диаграмм в реляционные таблицы в случае связи 1:1.

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

27.Правила  преобразования  ER-диаграмм в реляционные таблицы в случае связи 1:М, М:N.

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

28. Нормализация таблиц, ее цель. Первая  нормальная форма. Вторая нормальная  форма. Третья нормальная форма.

Нормализация отношений  – процесс, позволяющий гарантировать  эффективность структур данных в  реляц БД. Изменение отношений  не должно привод. к двусмысленности или потере инфо. Перестройка набора отношений при вводе новых типов д.б. min. Нормализованным наз. отношение, у кот. кажд. еомпонента кортежа явл. простой, не сост. из группы значений. Процедура декомпозиции позвол. заменить данн. множество др. множ-м, явл. проекцией исходн. множ-ва и имеет более прост. стр-ру. Реляц БД считается эфф, если она облад характеристиками. 1. Минимизация избыточности данных(В БД  присутствует   избыточность, если одни и те же данные находятся в неск местах. →память компа испол-ся неэкономно и времени на корректировку данных тратится больше). 2. Минимальное использование отсутствующих значений. 3. Предотвращение потери информации. Реляц БД считается эфф, если все ее таблицы наход как min в 3НФ.  Табл   находится в 1НФ, если все ее поля содержат только простые неделимые значения. Табл находится в 2НФ, если она удовлетворяет требованиям 1НФ и неключ поля зависят от первич ключа. Табл находится в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей. Транзитивная зависимость - функциональная зависимость между неключевыми полями.    

29.Концептуальное  проектирование, его цель и процедуры.    

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

30. Логическое проектирование, его  цель и процедуры.

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

1. Выбор модели данных.

2. Определение набора таблиц  исходя из ER-модели и их документирование. Для каждой сущности ER-модели создается таблица. Имя сущности – имя таблицы. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.

3. Нормализация таблиц

4. Проверка логической  модели данных  на предмет возможности выполнения всех транзакций, Транзакция – это набор действий, выполняемых отдельным пользователем или прикладной программой с целью изменения содержимого базы данных.

5. Определение требований  поддержки целостности данных  и их документирование. Эти требования  представляют собой ограничения,  которые вводятся с целью предотвратить  помещение в базу данных противоречивых  данных. Должны быть рассмотрены  следующие типы ограничений:

· обязательные данные. Выясняется, есть ли атрибуты, которые не могут  иметь Null-значений;

· ограничения для значений атрибутов. Определяются допустимые значения для атрибутов;

· целостность сущностей. Она достигается, если первичный  ключ сущности не содержит Null-значений;

· ссылочная целостность. Она понимается так, что значение внешнего ключа должно обязательно  присутствовать в первичном ключе  одной из строк таблицы для  родительской сущности;

· ограничения, накладываемые  бизнес-правилами

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

Результат логического проектирования:

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

- функциональные спецификации  программных модулей.

- набор возможных запросов  к базе данных.

 

 

 

 

 

 

 

 

 

 

 

 

31. Физическое проектирование, его  цель и процедуры.

При логическом проектировании отвечают на вопрос – что надо сделать, а при физическом – выбирается способ, как это сделать.

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

Процедуры физического проектирования следующие.

1. Проектирование таблиц  базы данных средствами выбранной  СУБД.

2. Реализация бизнес-правил  в среде выбранной СУБД. (Обновление  информации в таблицах может  быть ограничено бизнес-правилами.)

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

4. Разработка  стратегии защиты базы данных.

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

Результат: полностью готовая  к внедрению структура базы данных и набор реализуемых алгоритмов по её использованию.

Все этапы проектирования БД опираются на использование словарной  системы.

Словарная система – хранилище  информации об элементах данных в БД:

• Имена элементов
• Описание смыслового значения
• Характеристика элементов
• Информация о владельце
• Секретности
• Использование данных
• Связи с программами

32. Семантическая объектная модель. Пример объектной диаграммы.

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

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

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

Одной из наиболее распространённых семантических моделей данных является модель «сущность-связь» или ER-модель. Моделирование предметной области базируется на использовании графических диаграмм или ER-диаргамм.

Для моделирования данных в семантических объектах используется объектные диаграммы. Такие диаграммы  используются разработчиками баз данных для описания и визуального представления  структуры объектов. Объекты в  них отражаются в вертикально  ориентированных прямоугольниках. Имя объекта указывается внутри прямоугольника в верхней его  части, а затем следует список атрибутов по порядку их значимости для этого объекта.

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

33. Сase-средства для моделирования данных.

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

Инструментальные CASE-средства – программные  средства, поддерживающие процессы создания и сопровождения информационных систем, коорые включают следующие  этапы:

- анализ и формулировка требований  предметной области.

- проектирование БД и прикладного  программного обеспечения.

- генерацию кода для выбранной  СУБД и языка приложений.

- тестирование.

- документирование.

- обеспечение требуемого качества  работы и др.

Средства концептуального моделирования  базы данных (CASE-средства):

- Platinum/CA ErWin  и  AllFusion Data Model

- AllFusion Modeling Suit

Модели данных в  ErWin

Уровни представления моделей:

-   логический: абстрактный взгляд  на данные.

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

ErWin позволяет решить задачу  по переносу структуры данных  с одного сервера на другой.

Основные возможности ErWin:

- создание визуальной модели  различных видов.

- прямой инжиниринг и обратный, проверка синтаксиса модели.